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
Entity-Developer generates mixed lower uppercase SSDL names
We are investigating the issue.HCRoman wrote:some times extensions with lower case and other names with all upper case
Please specify the model elements, for which Guid is regenerated. How can we reproduce the problem?HCRoman wrote:all internal ed:Guid changes every time you change/import a model
HCRoman wrote:Why you change the naming for the *Designer.cs to Designer 1.cs.
We are investigating the issues.HCRoman wrote:Why the Model.info file is now included to the project???
GUIIDs recreated with every new creation from database
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
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
Re: GUIIDs recreated with every new creation from database
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 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?
Sorry, but it is not clear enough. Could you please give us an example?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.
Re: GUIIDs recreated with every new creation from database
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.Shalex wrote: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 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?
I use WinMerge to control for unwanted changes in my large model...
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!Shalex wrote:Sorry, but it is not clear enough. Could you please give us an example?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.
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
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.Shalex wrote:We are investigating the issue.HCRoman wrote:some times extensions with lower case and other names with all upper case
We call Guid.NewGuid() for each new element on the model.HCRoman wrote: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.Shalex wrote: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 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?
I use WinMerge to control for unwanted changes in my large model...
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 .
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 .