Suggestion: ID placeholder for AL to get rid of IDs

[megel]

trafficstars

Just an idea, what if we could remove IDs simply from AL development?

1. IMHO the IDs are not necessary when you write code in AL except when you define new objects or extend objects.
2. The NST compiler will check the IDs during publishing

Let's us a NAVautoID as placehloder which will be resolved and replced during publishing and compilation by the NST . This could look like this:

page NAVautoID "MyPage"
{
   // some code
}

table NAVautoID "MyTable"
{
   fields
   {
        field(NAVautoID; MyField; Integer)
        {}
   }
}

tableextension NAVautoID "MyTableExt" extends Item
{
   fields
   {
        field(NAVautoID; MyText; Text[30])
        {}
   }
}

In the application manifest app.json we could add a section / element where we are able to add JSON files which contains the licensed IDs e.g.:

{
     "NAVautoID": {
           "Table": ["50100..50150"],
           "Page": ["50100", "50102", "50200..50300"]
     }
}     

Could this work? What do you think?

[FSharpCSharp]

That sounds like a great idea! Then you would be able to completely save yourself the renumbering in the future. Furthermore, it would also be much easier to expand, and one would not always need to know the free IDs. I hope that Microsoft will take care of this issue in any case.

[esbenk]

Unfortunately not. From a compiler perspective it could, but not without major changes to the runtime.

Specifically tables are problematic. For synchronization and upgrade we rely the ids for a specific table to be fixed.

Persisted RecordIds contains the table id, and that will break if you suddenly get a different id for the table.

[megel]

@esbenk, I believe it could be possible. From outside we don't need the IDs and from inside, NAV can save the used IDs in a special table, for reuse after update by sync/upgrade. The identification of fields and tables can be done by Name and Type.

Another possibility is to add an unique ID e.g. a GUID to fields and objects. Both would not break something like persisted RecordIds, because the used (internally stored) ID is still the same.

The only question is, how to transfer the possible / licensed IDs to the NST? Add them to the app.json?

The big benefit, we could solve some problems of real life CI (described by @waldo1001 in his blog).

[kine]

It will be problematic when I will want to rename existing filed. It will automatically create new one instead rename.

[megel]

OK, lets solve this problem by adding a NAVUUID. With this Information the NST is able to rename the fields and Keep the internal used ID. The UUID can be generated automatic by VSCode Extension and is CI-Ready.

page NAVautoID "MyPage"
{
    NAVUUID = '89b90b7a-e30b-4c46-8ddc-2898796ce213';
   // some code
}

table NAVautoID "MyTable"
{
   NAVUUID = 'dbce3918-4baf-4596-8ff7-89168010ae5f';
   fields
   {
        field(NAVautoID; MyField; Integer)
        {
             NAVUUID = 'afaf539b-212f-43e7-8de4-486562e00e20';
        }
   }
}

tableextension NAVautoID "MyTableExt" extends Item
{
   fields
   {
        field(NAVautoID; MyText; Text[30])
        {
             NAVUUID = 'b8ff2b16-6a9a-4e95-b027-f95758063a07';
        }
   }
}

@kine, @esbenk, what do you think?

[RafaelKoch]

Is the NAVUUID just another Identifier just like the combination of type and ID we have today? Anyway I still like the idea a lot because that could maybe help build for topics most of us will be struggling with that are not directly related to getting rid of IDs. Just some thoughts:

• help identifying a connection between a label/caption in a translation file and its location in the code
• help to identify if extension dependencies are actually really used. We could use the unique identifiers proposed to build a "database" of given structures and query if they are used more easily.

• probably more...

[JSebastianN]

Good thinking! As an ISV who maintain a solution from NAV 2009 til AL, I work hard to have the same code in the same objects for easy maintenance. So I need my AL file to still contain a reference to a numbered object for the c/side versions...

[kalberes]

Long term plan. We are at the early namespace phase