Entity-Developer generates mixed lower uppercase SSDL names

Discussion of open issues, suggestions and bugs regarding Entity Developer - ORM modeling and code generation tool
Post Reply
HCRoman
Posts: 55
Joined: Wed 12 Aug 2009 05:47

Entity-Developer generates mixed lower uppercase SSDL names

Post by HCRoman » Mon 14 Nov 2011 12:58

Hi devart,

the new version of Entity-Developer
build 6.50.244 / 4.1.71
hase some new pluralization "feature"??

The SSDL names imported from Oracle are every time uppercase and the pluralization extensions generated by devart are every time lower case.

In the new version it comes mixed, some times the old behav and other names with all upper case.

It seems to depend on the last character from the original name,
if it is a digit or an vowel, all is pluralized now to upper case, else the pluralization is as old behav lower case????

---------
(This is as long as the Guid exists in the edml)

Second thing ist the ugly thing, that all internal ed:Guid changes every time you change/import a model. This does not help to find out what has really changed.....
Why this internal number is not deterministic calculated and will only change if the property has changed???


--------------

Why you change the naming for the *Designer.cs to Designer 1.cs. No please not!!!

Why the Model.info file is now included to the project??? No please not!

Please do not change such basic things with every version!!!

Let the user decide how to name the files, diagrams, view-files etc. and do not change this, please.

Any help or idea for all topics


Tnx

Roman

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Thu 17 Nov 2011 17:53

HCRoman wrote:some times extensions with lower case and other names with all upper case
We are investigating the issue.
HCRoman wrote:all internal ed:Guid changes every time you change/import a model
Please specify the model elements, for which Guid is regenerated. How can we reproduce the problem?
HCRoman wrote:Why you change the naming for the *Designer.cs to Designer 1.cs.
HCRoman wrote:Why the Model.info file is now included to the project???
We are investigating the issues.

HCRoman
Posts: 55
Joined: Wed 12 Aug 2009 05:47

GUIIDs recreated with every new creation from database

Post by HCRoman » Fri 18 Nov 2011 08:17

Hi devart team,

if you do not use merge, couse of some missing features and create a new model from database twice, you will get two edml files with all ed:Guid are different from the previous generated file! Why?

try it out.

If you want to preserve really all user changes on names and column data types and table splitting, you have to mark and copy each user changed attribute in your edps file as modified, save the original generated in edps and during "merge" you can compare original versions and can mark it only as a change if the original has changed compared to the new generated one.
As a good designer help, you could color all "user changes", so you can find them easier.

For example in oracle we have a lot of NUMBER(1) columns and you can not distinguish if it is a bool or really a number(1), so you have to change this in the model...

Roman

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Re: GUIIDs recreated with every new creation from database

Post by Shalex » Fri 18 Nov 2011 13:33

HCRoman wrote:if you do not use merge, couse of some missing features and create a new model from database twice, you will get two edml files with all ed:Guid are different from the previous generated file! Why?
This is a designed behaviour. ed:Guid is our internal attribute and should identify uniquely each element on the model. How are you using ed:Guid?
HCRoman wrote:If you want to preserve really all user changes on names and column data types and table splitting, you have to mark and copy each user changed attribute in your edps file as modified, save the original generated in edps and during "merge" you can compare original versions and can mark it only as a change if the original has changed compared to the new generated one.
As a good designer help, you could color all "user changes", so you can find them easier.
Sorry, but it is not clear enough. Could you please give us an example?

HCRoman
Posts: 55
Joined: Wed 12 Aug 2009 05:47

Re: GUIIDs recreated with every new creation from database

Post by HCRoman » Mon 21 Nov 2011 09:10

Shalex wrote:
HCRoman wrote:if you do not use merge, couse of some missing features and create a new model from database twice, you will get two edml files with all ed:Guid are different from the previous generated file! Why?
This is a designed behaviour. ed:Guid is our internal attribute and should identify uniquely each element on the model. How are you using ed:Guid?
I do not "use" it, but if you use WinMerge for instance, to "compare" old and new edml, you will have tons of "differences" hiding the real changes.
I use WinMerge to control for unwanted changes in my large model...
Shalex wrote:
HCRoman wrote:If you want to preserve really all user changes on names and column data types and table splitting, you have to mark and copy each user changed attribute in your edps file as modified, save the original generated in edps and during "merge" you can compare original versions and can mark it only as a change if the original has changed compared to the new generated one.
As a good designer help, you could color all "user changes", so you can find them easier.
Sorry, but it is not clear enough. Could you please give us an example?
Ok, you have an table TEST under oracle database with column VALID as NUMBER(1) and column FLAG as NUMBER(1), both are imported as BOOL by default. You change the second column to INT (int32) because it is not a bool!

Save and merge the model again and now you will see the second colum as "changed", but it is not the case. If you would have saved the "original" imported BOOL data type in the edps than you could see "nothing has changed" on that table column since last import.

Same could be done for any user "renames" of associations, entity sets or column names..

Is this explained enough?

Roman

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Mon 21 Nov 2011 16:42

Shalex wrote:
HCRoman wrote:some times extensions with lower case and other names with all upper case
We are investigating the issue.
Starting from the next build, the behaviour will be the following: "S" will be added to the name that consists of only upper letters and/or numbers, "s" - in the opposite case.
HCRoman wrote:
Shalex wrote:
HCRoman wrote: if you do not use merge, couse of some missing features and create a new model from database twice, you will get two edml files with all ed:Guid are different from the previous generated file! Why?
This is a designed behaviour. ed:Guid is our internal attribute and should identify uniquely each element on the model. How are you using ed:Guid?
I do not "use" it, but if you use WinMerge for instance, to "compare" old and new edml, you will have tons of "differences" hiding the real changes.
I use WinMerge to control for unwanted changes in my large model...
We call Guid.NewGuid() for each new element on the model.

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Mon 21 Nov 2011 16:51

HCRoman wrote: Why you change the naming for the *Designer.cs to Designer 1.cs.
The issue is fixed. Look forward to the next build.

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Mon 21 Nov 2011 17:55

HCRoman wrote:Why the Model.info file is now included to the project???
The behaviour is changed back. Look forward to the next build.

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Thu 24 Nov 2011 15:30

New build of Entity Developer 4.1.77 is available for download now!
It can be downloaded from http://www.devart.com/entitydeveloper/download.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://www.devart.com/forums/viewtopic.php?t=22652 .

Post Reply