Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> Loosing "Fields mapped on relations" setting
 

Pages: 1
Bugs & Issues
Loosing "Fields mapped on relations" setting
Page:1/1 

  Print all messages in this thread  
Poster Message
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 13-Jun-2008 09:44:42.  
Hello,

I run into the following problem:

1) Using the designer I'm modifying a "Fields mapped on relations" default fieldname on a relation of type m:1, hidden=false.
2) I save the changes to the project file.
3) I generate the code (F7)

Result: In my code I can use the modified fieldname. Perfect!

Then .... the problem:

From within VS2008 I use a batch file to refresh the model and regenerate code (using the same project as I used in the designer, and using CliRefresher.exe and CliGenerator.exe). However, when I run this batch file, the manually modified field name is being replaced again by the autogenerated default fieldname.


My question is: should this work like this, or could I expect the manually changed fieldname to remain changed as desired. What can I do to preserve the fieldname?

Paul

ps. I'm using llblgenpro version 2.5 dec 5th 2007
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14473 posts
# Posted on: 13-Jun-2008 09:51:08.  
If you re-open the Designer before using the batch file to refresh and regenerate the code, would you find the field name as you have renamed it?

And now (after refresh and re-generation) if you open the Designer would you find the original field name or the renamed one?


  Top
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 13-Jun-2008 09:57:50.  
Hello Walaa,
thanx for the quick reply.
I tested it again with refreshing in the designer ....
And indeed ... now it also changes back to the default.

I found the following message in the refresh log:

Field 'Portal_ChildPortal' mapped onto relation 'Portal_SiteMapRule.ChildPortalId - Portal_Portal.PortalId (m:1)' has been renamed to 'Portal_Portal_' (Sync with name of target)


Portal_ChildPortal is the name I gave it manually, Portal_Portal_ is the name it was given by llblgen. So this shows that it actually is overriden by the refresh process.

hummm ... now what? Confused

Paul


ps:
I looked at project settings, found:
SyncMappedElementNamesAfterRefresh = true

I put this on true, in order to make sure that changes to the datamodel would immediatly appear in the regenerated code. Which is still what I want without exception ... ahum, except this exception. Dissapointed

The problem is that the fieldname llblgen generates is not coming from the database either, it is a 'creation' of logic in llblgen.
Do you see a way of dealing with this???






  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14473 posts
# Posted on: 13-Jun-2008 10:19:50.  
This issue was discussed before:
http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12575
http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=8982


  Top
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 13-Jun-2008 10:45:57.  
Walaa,

I read those links. It indeed 'kind-off' talks about the same topic. However i see a difference.

With the setting of SyncMappedElementNamesAfterRefresh is set to true, one counts on the fact that each change in the database is reflected in the 'refreshed' and 'regenerated' code. I hope this will never change!

The exmaple otis gives, with a field ABC in the db, changed manually to XYZ in the designer. Later changed in the db to DEF .. etc.. this is all ugly. I don't want this type of discrepancies ... therefore 100% mapping.

However .... fields mapped on relations gives the field a name which is not 100% derived from the database, the trailing underscore to the fieldname is a 'creation' of the llblgen logic.

In this case a different solutions can be thought of, I'm sure.

Paul
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14473 posts
# Posted on: 13-Jun-2008 10:51:41.  
But it's also generated based on the database table name.
So if Order has a Customer filed mapped on the relation, then on the database you rename the Customer table to be "Client", when you refresh the catalog with that flag turned on, the field should read Client instead of Customer.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37409 posts
# Posted on: 13-Jun-2008 11:14:41.  
We've added a feature to v2.6, where you can say that manually renamed field names (and fields mapped onto relations) aren't affected by the sync feature. So in v2.5, this wasn't fixable, as it would require information stored inside the project file which then would cause versioning issues among users, however in v2.6 this should work properly: after you've renamed the field, the field shouldn't be changed back, if you've set 'SyncRenamedFieldElementsAfterRefresh' to false Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 13-Jun-2008 13:36:24.  
Walaa & Otis ...
Briljant!!!
Thanx very much!!!

Paul


  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.