search

vjekob / al-objid

Manage object IDs in multi-user environments with mind-boggling simplicity.
MIT License
29 stars 18 forks source link

Feature: Cross-app ID synchronization #1

Closed vjekob closed 2 years ago

vjekob commented 3 years ago

Problem

Right now (v1.0.3), Ninja synchronizes app IDs per app. This means that every app submits its own ranges definitions and tracks its own consumption of IDs. This covers the basic needs of development teams who develop and maintain simple BC apps, especially monolithic ones.

However, for mature development teams developing an app hierarchy with dependencies across multiple apps (which makes an awful lot of sense for anything more complex than a pocket calculator), multiple apps will consume IDs from the same pool of IDs to prevent object collision when dependencies are installed.

The current behavior of Ninja just won't cut it. If Ninja is not capable of tracking object IDs across entire pools of apps, it is simply unusable except for simple app scenarios.

Possible approaches

This is how I intend to handle this.

App pool creation and maintenance

There will be three commands:

  1. Create app pool: it will create a new app pool in the back end and will return the id. It will also update the .objidauth file (new name is due!) and store that id in there.
  2. Join app pool: it will ask the user for pool id, and will store that pool id in .objidauth.
  3. Leave app pool: opposite of point 2.

Front-end logic

When sending any requests to the back end, Ninja will include the pool id along the app id whenever there is pool id info in .objidauth.

Back end

Pools will be also maintained in the back end - it will know which apps belong to which pool. When a pool is created, the app from where it was created will be automatically added to the pool. Also, when an app joins or leaves the pool, the back-end cache is updated accordingly.

When getNextId request is processed, if pool id is not included for an app that is known to belong to a pool, there will be a warning in the front end about this.

When syncIds request is processed, if pool id is not passed along the app id, back end refuses to process the request. This situation indicates that the local repo sending the request is probably using an outdated .objidauth and is probably not in sync with latest master branch, so this error will force it to update.

Conclusion

This is how I intend to solve this. This feature is an absolute must for mature development teams.

If you have any comments, about the above description, or think it won't get the job done and something else is needed. please let me know in the comments.

waldo1001 commented 3 years ago

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:

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 ;-).

fvet commented 3 years ago

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.

vjekob commented 3 years ago

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.

pzentner commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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?

vjekob commented 3 years ago

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.

GreatScott000 commented 2 years ago

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!

vjekob commented 2 years ago

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 commented 2 years ago

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