Feature: Cross-app ID synchronization about al-objid

[fvet]

For new apps (PTE, ISV, AppSource, ...), it makes absolute sense to assign a dedicated object range per app and use this as a best practice.

For legacy apps (stripping a monolith in smaller apps / lift and shift, without renumbering the object id's) we are somewhat forced to support this 'bad practice', which makes the idea of an 'app pool' very attractive.

[waldo1001]

My personal opinion: why this feature? Why supporting a "bad practice" as "a number one feature"? 😉

I certainly understand that it works, and that people would "save number ranges". But it's so easy to get a new range .. so just get a new range - a dedicated one for every single app.

Just imagine in the future:

• this extension doesn't exist anymore - so we'd need to start supporting this "ability" ourselves
• a conflict between two apps DOES get through and conflicts start to happen on AppSource
• MS doesn't allow overlapping number ranges anymore (which they shouldn't have in the first place)
• ...

I mean: having dedicated ranges just makes sure that THAT level of conflict (between apps) will never ever happen. Why take the chance? To save some "numbers"?

Meh .. not me. I can't see this as a good practice to anything .. so in my company, it won't be used 🤪.

Just wanted to give my opinion, that's all .. you do what you like, of course ;-).

[vjekob]

The status is that my focus has recently been on other projects (those that bring food to my kids mouths) so Ninja was put on hold. I hope I'll have more time to focus on this feature soon.

[vjekob]

Released in v2.5.0

Check the release notes: https://github.com/vjekob/al-objid/blob/master/vscode-extension/docs/ReleaseNotes.v2.5.0.md

[vjekob]

Couple of things:

1. First, thanks for commenting, and thanks, waldo, for running a poll on Twitter. It shows me that this feature is not only far less important than I got an impression on Friday at Beerinar, but also far more of a bad practice than I originally thought so.
2. I have already done the first steps in building what I proposed above. The back end is essentially done, it already supports app pools. There is nothing in the front end, yet.

I want to see where polls end.

And finally, the most important part here in this feature discussion - let's not discuss whether this is a good or a bad practice. Let's discuss how to do it in the most intuitive and the safest way.

On top of what I proposed above, I'd add one more thing: before you create a pool or join an app into pool, there would be a "are you absolutely totally sure about this" with the essential "Learn more" button to take you to a wiki or md page that explains why it's a bad idea in the first place.

[vjekob]

I see your point TeusV. This feature is definitely coming, I just have to complete this back-end migration to "v2" that I blogged about yesterday.

About app pool ID synchronization, the only way it can properly work is that you either prepare a workspace with all apps that share a pool (preferred way!) and then sync the entire workspace, or that you collect IDs for the pool locally before submitting them once. This second approach would be more complicated.

But this is coming, trust me. I have done quite a lot already about this, I just need to complete it.

[pzentner]

I actually do think that it is somewhat difficult to manage object ranges for customer specific apps for on premise when you can't do cross app I'd sharing, but I also agree that it's bad practice, potentially.

I was all excited about this feature, but then, thinking about it, it makes a lot more sense to manage app ranges via customer license than assigning id's to a pool of apps.

UT, I was exactly 8n the same thought process - this is a must have. Well, the must have is clear I'd management on the license side then.

The way I would split large apps is to move the existing objects and then assign a new object range to each app for new objects, this would also resolve the need for that.

[fvet]

My personal opinion: why this feature? Why supporting a "bad practice" as "a number one feature"? 😉

I certainly understand that it works, and that people would "save number ranges". But it's so easy to get a new range .. so just get a new range - a dedicated one for every single app.

Just imagine in the future:

• this extension doesn't exist anymore - so we'd need to start supporting this "ability" ourselves
• a conflict between two apps DOES get through and conflicts start to happen on AppSource
• MS doesn't allow overlapping number ranges anymore (which they shouldn't have in the first place)
• ...

I mean: having dedicated ranges just makes sure that THAT level of conflict (between apps) will never ever happen. Why take the chance? To save some "numbers"?

Meh .. not me. I can't see this as a good practice to anything .. so in my company, it won't be used 🤪.

Just wanted to give my opinion, that's all .. you do what you like, of course ;-).

@waldo1001

Just curious on which idRanges you assign on your test apps?

Our current approach is to set a dedicated range per repo / app (e.g. 100 objects) and use this same range for the Test app too. (it will mostly be the number of codeunits that will force us to increase the range / no. of objects)

With this approach, I'd definitly have to create an App pool for each repo (include the app id + test app id)

[dzzzb]

For legacy apps (stripping a monolith in smaller apps / lift and shift, without renumbering the object id's) we are somewhat forced to support this 'bad practice', which makes the idea of an 'app pool' very attractive.

Agreed. Let's face it, we don't live in an ideal world, so sometimes a customer is going to ask for several bits of functionality you offer, but not be willing to amend their licence. So you go to renumber the various apps into their range (ideally in a Git branch, etc.) - but then you have to contend with other developers on the 'main' monolith, who will probably end up using the IDs you're trying to keep free for the apps you're adding to their monolithic licence. Supporting pools could avoid most of the hassle

[TeusV]

For us, this is the feature that would change Ninja from useless into the tool we have been looking for. In fact, much better than what we've been looking for. Thanks a lot for all the effort and the dedication, Vjeko!

Just like someone else mentioned before, due to legacy we've ended up with multiple apps with the same id ranges.

The app pool solution sounds great. One concern though: when several apps have joined the same app pool, a 'replace synchronization' could do quite some damage. In order to reduce chances of this happening accidentally, maybe when running replace synchronization when inside an app pool it could (at least) be pointed out that this would remove all reservations of other apps inside the same pool?

[GreatScott000]

Just wondering what the status of this is. I understand the arguments pro/con but this would be very useful particularly for PTE heavy client.

No pressure, I love the tool!