Hi

if I have two tables in the database where one is a subtype of the other and the order of the keys are in a different order or do not have the same index the FK <-> PK mapping is not correct.

Christoph

Please specify the llblgen pro version, db type and version. Also could you attach the lgp file.

Here is a complete Test Project.

There is a supertype

ElementName( PK: ElementId, ElementNameType, Locale)

and two subtypes

SimpleElementName( PK: ElementId, Locale, ElementNameType) ComplexElementName( PK: ElementId, Locale, ElementNameType)

Please note that ElementType and Locale have a different order in the subertype.

When you look at the output you can see that in the subtype (in this case SimpleElementName) LLBLGen tries to save the entity with the field order of the supertype for the PK/FK fields

Christoph

LLBLGen 2.6, 2.6.9.1202 from 02.12.2009 SQL Server Express 2008

really odd, we'll look into it. It's particularly weird because the code is designed to deal with differences in ordinal, but perhaps your project triggers a weakness.

Please next time, don't sent in a project made with a beta version of vs.net (2010 in this case). Thanks.

(edit) turns out only the solution wasn't loadable, the project files themselves were ok

The project in the designer is OK, all fields are linked to the same fields. Running tests now.

Ups, forgot that with the Visual Studio 2010 projects

It's a bug in the runtime. You can verify this with the following code:

Console.WriteLine("LinkedFieldsAreEqual: {0}", 
        elementNameEntity.Fields[(int)SimpleElementNameFieldIndex.Locale_ElementName].CurrentValue ==
            elementNameEntity.Fields[(int)SimpleElementNameFieldIndex.Locale].CurrentValue);

right before adapter.SaveEntity(...);

The fields referred to are representing the same field, one is for the supertype and one is for the subtype. They're 'linked' under the hood, so if you set one of these fields to a value, the other is set too.

It goes wrong when the Fields for an entity (e.g. simpleelementname) are produced: it then tries to link the pk fields together, however it does this using simple index math, while it should consult the indices stored in the inheritance provider.

It is fixable, but will take some refactoring in the code. (InheritanceInfoProvider has the distinguishing field indexes, in the order of the fields in the relationship between supertype and subtype, so always in the order of the supertype, so it should use that instead.).

V3 isn't affected as a subtype inherits the PK from the supertype, and these fields are emitted in that order, always, before all other fields and always sorted on name.

I hope to have a fix for you tomorrow (wednesday).

It doesn't hurry. I just came across this issue. After figuring what happened it was easy to fix and sort the PK/FK in the database.

We've decided not to fix this, although we have code running which corrects this issue. The main problem is that the linking of the fields is an operation which has to be done for every entity which is instantiated and our code requires multiple loops and therefore will require way more operations per entity instance than the current routine. This means that fetching entities over time will be slower than with the current routine. As it's an edge case and v3 doesn't have the issue, we've decided it's not worth it to include the fix. We can speed up the code a bit with extra precalculation (the main problem is finding the start indexes per entity in a bucket of fields, which can be precalculated, as well as traversing the distinguishing indexes per super/subtype pair.

I've commented out the code in the codebase, so if you really demand us to add it, we'll add it, however as the case is really rare (you're the first one in 5 years we support inheritance who runs into this ) we are a bit reluctant to add this extra processing for this rare, edge case.

So, it's easy to fix when you know it. Perhaps you could add a note in the documentation for this fact that the order of PK/FK does matter in the target per entity inheritance.

This depends how long you will support the version 2.6 as you mentioned that this case does not occur in the new 3.0 version.

Anyway...

Thank you

Christoph