Al: Error: The request failed with code 422, reason: An item with the same key has already been added.

[markbrummel]

Whatever I do, I cannot add a table extension without getting error code 422.

When I remove the Table Extension the extension publishes fine.

The error occurs when publishing the extension, not when building.

[waldo1001]

I have had several errors - different occasions - not a clear flow to reproduce.. .

I always have a fix-script which is just going to rebuild the database. That always works :-).

[StanislawStempin]

Mark, could you provide AL code that triggers this issue and the stack trace from Event Log?

[markbrummel]

If you clone this project on GitHub you should get the error when you publish.

https://github.com/markbrummel/ALExampeExtension

I will also create a smaller project and put it on GitHub

Server instance: Navision_main
Category: Development
ClientSessionId: 00000000-0000-0000-0000-000000000000
ClientActivityId: 00000000-0000-0000-0000-000000000000
ServerSessionUniqueId: 822f8cce-d8a0-466a-a19a-7e618c240d60
ServerActivityId: eb00289c-f846-419e-b076-b50bfd3e2355
EventTime: 06/29/2017 13:48:11
Message Failed request -- Method:POST; Url:http://localhost:7049/Navision_main/dev/apps?tenant=default; StatusCode:422; ReasonPhrase:Unprocessable Entity; ResponseBody: {"Message":"\r\nAn item with the same key has already been added.\r\n"}
ProcessId: 3324
Tag: 00000LY
ThreadId: 1489
CounterInformation:

[markbrummel]

Here is a smaller project just for this issue.

https://github.com/markbrummel/422Error

[ajkauffmann]

Isn't it the same error as this one: https://github.com/Microsoft/AL/issues/290

Hmm.. code is the same (422) but message is different...

[waldo1001]

You create a tableextension on a table that is part of the same extension??
why do that?

[markbrummel]

Why not? C# has partial classes right? Worked fine in April update.

[ajkauffmann]

That's in interesting idea. Partial classes definitely come with some advantages.

In C# it is a documented feature and fully supported by Visual Studio. Haven't seen that in AL though. Then you should have something like partial table or partial tableextension, right?

At the other hand, extensions are already partial by nature. Difference with C# would still be that in C# you have to mark all parts as partial while in AL you have a base object that is not identifiable as partial and one or more extension (partial) objects. In that way is not exactly the same.

Having said that, I guess that combining table and tableextension in one workspace has not been part of the design or at least works by coincidence. ;-)

[waldo1001]

I think you both forget one thing: we are not talking classes .. we're talking tables.
So IF you want to compare, compare with a SQL table (or do we create tables in C# as well :-)?

Even more - when we create a table-extension, we create a NEW table on SQL Server with the extra fields. Do we really want this? Is this a clean design - knowing it's all part of the same extension?

In my book, this doesn't open up any opportunities .. I really don't see any use of it. If you have examples .. I'm all ears :-). The only opportunity I see with this, is to completely make my design unsupportable - which is a form of job-protection ;-).

If this should/would be supported, I don't want to know the implications on things like dependent extensions, or the data-upgrade, or ... . What if I migrate from a table/table ext. design to a decent "table only" design .. how do I migrate my data? From Item.Field to .. uhm .. Item.Field?

I think there is one decent way to "solve" this error, and that is to not allow this design in the compiler in the first place...

just my €0.02

[ajkauffmann]

Waldo has a point here. With AL we have the same design as in C/AL: mixing table definitions with code. Which is, in my view, a wrong design.

I would really like to see something like a table object that only defines the table schema and nothing else. That could be combined with a separate object that holds the code. Let's say a codeunit where you subscribe to all event triggers from the fields and the table. Now that would be clean coding! No more code on table objects, think a few seconds about that... Do the same with page that would make me even more happy. Reports already have such design with separate layout files.

And then we could have a discussion about partial classes as in: have partial codeunit objects that, like C#, will be combined into one codeunit object during compilation. With all the advantages and restrictions that come with such design.

If there is a moment in history that NAV could go this way, it is now, with the move to AL. I mean, we already can separate code from tables because all events you need are there. Move the base code from tables to a partial codeunit and let customizations be done in another partial codeunit that is combined on compilation.

Man, you really got me started...

[markbrummel]

Guys, you are making this way to complicated. It worked just fine in the april update and it was broken in june. So bug.

Yes, off course I am separating code from a table definition. This has always been smart and table extensions are a good way forward.

[waldo1001]

Lol.. telling you that your design has no use, and is too complicated .. is hardly "making it too complicated". It is telling you that you are making it too complicated.. .

"It worked just fine in april" .. lol. Please make a distinction between a "release" and a "pre-release"... It might very well be that the restriction just wasn't implemented yet.

But anyway .. we'll see what happens. If Microsoft decides to support it, I can agree with that. I'm not the one advocating "restrictions in compilers" or "data dictionaries" or .. . "With great power comes great responsibility".. . I'll just teach my developers to not do it that way you do it.

[ajkauffmann]

Come on, you started with complicating things... I mean, trying to create a table and a tableextension for it in one workspace. And then you try to create a function InitSetupRecord in both objects with exactly the same code. That looks to me like you tried to force overloading functions. Something that isn't supported in AL as far as I know. How do you know which function is executed, the one from the table or the one from the tableextension? Not that I'm against that principle by the way, but then please with official support in the AL language.

I would consider it a bug if your code is actually working...

[markbrummel]

Can we keep it polite please gents? I think it should work and it can have benefits. Enjoy your weekends.

[ajkauffmann]

No offense Mark, we know each other. This is just a nice discussion about a feature, it's not personal. Far from that. ;-)

I see a lot of benefits in what you were trying to achieve. No doubt about that. Would love to see official support because that would not only go for the combination you tried but hopefully also for overriding functions from the base application.

[markbrummel]

This is a public forum, not yammer. People who read this don't know our backgrounds.

I was not trying to overload. Great idea. Did you notice that the error that the new compiler gives us contains the word overloading?

There are two options.

1. The compiler gives an error

2. I can publish my app

Currently the compiler does not give an error and combined with the fact that in april it worked I have good hope.

With vscode now almost forcing people to implement distributed development it can have huge benefits. Also we now have where used so finding code is much easier.

Waldo, I am not drunk, actually I am at Schiphol not feeling so well. Only had water and cola.

I am offended by your rudeness on an open platform.

[waldo1001]

Well, I appologize if I offended you. Not my intention in any way.

But I give up on this topic though.. . I have not the feeling that my arguments are being taken serious anyway ..

[StanislawStempin]

Thanks for a good discussion. A few things that I'd like to mention:

1) Partial objects - there is an existing suggestion for it and we are considering adding support for it. Would be great to get more arguments for/against posted here: https://github.com/Microsoft/AL/issues/64

2) Table and table extension in the same project
The jury is still out on whether this should be a supported scenario or not. Currently it is supported and what Mark ran into is just a bug. From one side we want to provide flexibility of how developers want to structure AL code. From the other side using table extensions (with new fields) has negative performance consequences as each table extension object adds a new SQL table that needs to be kept in sync with the base table. It also brings limitations such as not being able to define a key that contains both a base field + extension field. So generally we would discourage the use of this approach in final, production code.

[markbrummel]

Thanks.

I am not looking to add fields in this scenario. I was just considering (nothing final) to add code.

I agree adding fields would be awkward.