LLBL Pro 4.2 build 16 April

I have supertype BoxMaster having subtypes: - BoxLotMaster - OuterBoxMaster

Then there is entity Box2BoxLog to provide hierarchy of boxes packed inside other outerboxes Box2BoxLog entity has fields: - ChildBoxID - ParentBoxID

where ChildBoxID has relationship to supertype BoxMaster:BoxID field ParentBoxID has relationship to subtype Outerbox:BoxID field see attachement

The problem is that designer adds two times relationship called "Box2BoxLogs" and then it causes error in generated OuterBoxMasterEntity.vb

I have to rename manualy relationship name in designer to "Box2BoxLogs_" to get it work.

On the other hand if I simply relink relationship this way : Box2Box: ParentBoxID ->BoxMaster:BoxID (instead of ->Outerbox:BoxID) then designer automatically generates also two relationship names like this: "Box2BoxLogs" and ""Box2BoxLogs". Means "" is added to the second relations to avoid naming conflict.

Therefore no error in generated code in thie case

I hope you get the point and try to improve designer to correctly rename relationships in TPE scenario.

Please try the latest build to see if it resolves the problem first.

Same in the latest July 21 build

Do you have changed the patterns for names for navigators etc. ? (as we don't have the project/preferences here, we have to know the details to be able to reproduce it)

No change in settings.

As I said, if I link 1 table twice to another table to ParentID and ChildID, the relationship naming works fine. The second one, gets suffix "_" to avoid duplicity.

But in iheritance scenario, where SuperType links to ChildID while SubType links to ParentID, then sufix "_" is not used

I added anothe screenshot of expanded relationships in designer, you see, that in subtype Outerbox the relationship named as Box2BoxLogs is inherited from supertype but also added again withe the same name without adding suffix as "Box2BoxLogs_" automatically.

I added anothe screenshot of expanded relationships in designer

Can't find them, please make sure you attach the screenshots.

sorry, forgot

You will need to change the Navigator Pattern in the project settings to include the StartEntityName as well. ({$EndEntityName}{$StartEntityFieldNames}).

Thanks Walaa, I tried but then I can see warning window:

Exception message:

Exception type: ValidationException The name 'SaveLinkLogsSerialId' is already in use by a field, navigator or other element.

Well, looks like I have to rename navigator manually to get rid of reported problem.

You removed the screenshots? If I use the default patterns, e.g. {$EndEntityName$S} for Navigator mapped onto one many to one pattern, I get 2 navigators in Box2BoxLog, BoxMaster and OuterBoxMaster.

I've attached the project I used to reproduce your problem (which I couldn't). Changing the patterns might create duplicates, but I don't know which patterns you used. Also, if the patterns are changed and which do result in duplicates, best thing to do is to change the patterns, as Walaa said.

Otis, I prepared in the meantime sample DB and project as well as screencast

Pls check attached SQL 2008R2 BAK + project and screencast URL: http://screencast.com/t/wyu0H9YH

Hope that helps, thanks!

Ah I now see where the issue is, not in Box2BoxLog (which I thought it was) but in OuterboxMaster. Looking into it!

The main issue occurs when an entity is made a subtype of another entity: because during reverse engineering this can't happen, only after reverse engineering took place and you e.g.. execute Entities -> Construct Target-per-Entity hierarchies. There, it doesn't check whether duplicate navigators occur.

Another moment when this happens is when you reverse engineer an entity E and it introduces navigators in existing entities (e.g. you remove Box2BoxLog and re-add it through reverse engineering).

Those two spots are where we'll look into fixing things. Hopefully it's a quick fix

Thanks Otis, workaround is simple, just manualy rename one of navigators to avoid duplicity. Means not urgent issue

Anyway it would be really nice to get it from designer automatically

Looking fwd to v.5

We'll add a validation error for the situation where due to B is made a subtype of A, B contains a duplicate nativator. We can't rename them automatically because which one to rename? If we rename one, the user's code will break but which navigator got renamed? So the user has to do that manually.

(The validation simply means that if there's a duplicate navigator, the error pops up).

The other situation, where you have BoxLotMaster, BoxMaster and OuterBoxMaster in an inheritance hierarchy and you then reverse engineer Box2BoxLog, you'll get navigators added to OuterBoxMaster (one directly, one through inheritance) and we'll then rename one, as none of them existed, or if one already existed (not your situation, but it's thinkable in another situation), we'll rename the newly created navigator.

Rosacek wrote:

Thanks Otis, workaround is simple, just manualy rename one of navigators to avoid duplicity. Means not urgent issue

Anyway it would be really nice to get it from designer automatically

the workaround is indeed simple, but we don't want our users to manually do things if they can be automated

Looking fwd to v.5

The derived modeling editor had a major breakthrough last week so we're making big progress now with that major feature, let's hope things go smooth now and we can ship a new CTP within a month

In the first scenario (making B the subtype of A in designer) you can catch it in that moment, show some warning window with those two conflicting navigators and let user deside which navigator to rename immediatelly.

Anyway your proposal sounds ok as well. R.

It's a catch-22 situation when determining duplicates when creating relationships, as in your case the duplicate occurs only after the relationship has been added, and during the creation the relationship itself doesn't know the inheritance scenario of both sides. It sucks that this isn't solveable other than with a validation but for now it's what we can do.

We have added a validation rule so it at least is picked up by the validation and not as a compile error after code generation. Manual editing the navigator is then still the only option to fix it though.

Validation is available in next build (29-jul-2015)

Just downloaded the latest build (29 July) and no change, no validation error

http://screencast.com/t/w7cBHuCR

Huh, you're absolutely right! The repro project now indeed doesn't give the error. Looking into it. !

Found it. Apparently an essential line of code wasn't present in the final build. I have no idea how that happened. Anyway, it's fixed now, verified it with final build. Pushing it now to the website, just a sec.

Please download the latest version from the website. (august 2nd)

We had to manually port the fix over to v5 and I think I did control-x instead of control-c on a statement, (a method call inside the list constructor call) which broke the fix in the 29th build.

Works now