Forum:  Bugs & Issues

Thread:  Relationship naming bug in TPE


Rosacek (User)   Posted on: 28-Jul-2015 14:32:23.
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.
Otis (LLBLGen Pro Team)   Posted on: 28-Jul-2015 18:58:26.
Please try the latest build to see if it resolves the problem first.

Rosacek (User)   Posted on: 28-Jul-2015 19:07:34.
Same in the latest July 21 build
Otis (LLBLGen Pro Team)   Posted on: 28-Jul-2015 20:41:27.
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)

Rosacek (User)   Posted on: 28-Jul-2015 20:51:33.
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.
Walaa (Support Team)   Posted on: 28-Jul-2015 21:15:42.
Quote:
I added anothe screenshot of expanded relationships in designer

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


Rosacek (User)   Posted on: 28-Jul-2015 21:17:16.
sorry, forgot
Walaa (Support Team)   Posted on: 28-Jul-2015 23:17:56.
You will need to change the Navigator Pattern in the project settings to include the StartEntityName as well. ({$EndEntityName}{$StartEntityFieldNames}).


Rosacek (User)   Posted on: 29-Jul-2015 01:04:45.
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.
Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2015 12:56:59.
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.


Rosacek (User)   Posted on: 29-Jul-2015 13:18:14.
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!
Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2015 15:31:18.
Ah I now see where the issue is, not in Box2BoxLog (which I thought it was) but in OuterboxMaster. Looking into it!

Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2015 16:00:04.
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 Regular Smiley
Rosacek (User)   Posted on: 29-Jul-2015 16:03:24.
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 Regular Smiley

Looking fwd to v.5 Cool


Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2015 16:16:10.
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 Regular Smiley

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

Quote:
Looking fwd to v.5 Cool

Regular Smiley 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 Regular Smiley

Rosacek (User)   Posted on: 29-Jul-2015 16:26:17.
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.




Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2015 17:59:10.
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)
Rosacek (User)   Posted on: 01-Aug-2015 14:28:40.
Just downloaded the latest build (29 July) and no change, no validation error

http://screencast.com/t/w7cBHuCR


Otis (LLBLGen Pro Team)   Posted on: 02-Aug-2015 17:48:19.
Huh, you're absolutely right! The repro project now indeed doesn't give the error. Confused Looking into it. !
Otis (LLBLGen Pro Team)   Posted on: 02-Aug-2015 18:02:53.
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.

Otis (LLBLGen Pro Team)   Posted on: 02-Aug-2015 18:19:09.
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.
Rosacek (User)   Posted on: 02-Aug-2015 20:35:48.
Works now Wink