Giters

vjekob / al-objid

Manage object IDs in multi-user environments with mind-boggling simplicity.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Maintaining allocated numbers

RadekZebrowski opened this issue · comments

commented

On the videos, where you showed how to use Ninja, we can see how easy is to allocate new id of the object.
What about de-allocation?
Let's consider some scenarios:

  • I started new object and instead of Query I created Page, then I realized the mistake and corrected the type ang get new id for it
  • I am re-working/removing part of the functionality so instead of 10 objects used earlier, it now uses 3 only (and no, those ones which I removed are not consecutive at the end - they sit randomly in the middle of the pool)
  • my autistic child figured out how to use ninja and "aligned" all pools so they end with 5
  • my cat run through the keyboard allocating an object accidently ;) etc..
    at the same time 20 other developers are doing their work - allocating new numbers (with or without mistakes) - so I would rather not refresh whole repo to match the allocation currently present in my local branch.

For now our plan, not perfect, would be:
when creating stable new release - re-sync repo with id's to match master.
But obviously allocations done in "work in progress" (in any branches not yet committed) will be lost and could cause overlapping...

Any suggestions how to handle this?

commented

This is one of the most important features in my TODO list already (from the beginning of Ninja, in fact). I have some ideas around how to make this as simple as possible.

These are (sub)features I have in mind:

  • Undoing last allocation
  • Reviewing any allocations which are known not to be pushed and are no longer associated with existing objects
  • Range Explorer will include object IDs as well, and you will be able to deallocate from there by right-clicking

Regarding your proposed workflow of resyncing when creating a stable new release, this is obviously a manual process that you can already do with auto-sync feature. I don't see how I could automate it beyond this, because "creating stable new release" is something very different for different teams.

commented

I made my comment about 'stable release' just to show that we can, with some limitation, handle the maintenance right now - so this is not super critical...

But the features you suggested above would be absolutely brilliant! That was exactly what I was hoping for :)

commented
  • Range Explorer will include object IDs as well, and you will be able to deallocate from there by right-clicking

When you will be developing this particular one could you show somehow differently (colors/font/etc) three types of allocations:

  • IDs which are allocated and which exist in current branch - so they are essentially OK (****)
  • IDs which are allocated and which do NOT exist in current branch - potentially allocated by other people / require review
  • IDs which are NOT allocated and do exist in current branch - so the update is required for them

(****) this part could also be not reported at all, or potentially hidden by default - when we are talking about hundreds / thousands of objects already present in the solution - it will be not very helpful to see them...

commented

I think the latest changes do fulfill all the things I mentioned in my original email. I am happy to close this one - great job!