Update Model – a Question of Identity – Part 2 of 3

re: Update Model – a Question of Identity – Part 2 of 3

Frans Bouma — Wed, 23 Jul 2008 10:29:31 GMT

I fail to see why you didn't solve this by adding the concept of 'grouping' of entitysets: you can have catalogs, catalogs have schemas, schemas have tables, views. The example you give above therefore doesn't give problems in that case because they're not in the same group, so an entity mapped on catalog1.schema1.customer knows it's not mapped on catalog2.schema4.customer

Some db's don't have catalogs, just schemas, but you can use a default name for 'catalog', and also if they don't support schemas, a default name for the schema.

The beauty of this is that you can immediately support multi-catalog projects as well, or multi-schema on oracle. This is how we do it in LLBLGen Pro and it works for oracle, sqlserver etc. and we can migrate a mapping layer just fine (including inheritance) to multiple catalogs being refreshed, simply because the mappings don't use cooked up names, but actually refer to elements in the meta-data which have unique names.

What I also find a little odd is that no-one at the EF team apparently has found it necessary to add an option to this refresher to make it the choice of the user if the model refresh logic will add new entities or update entities automatically. People who work from the DB want just 1 thing: refresh the catalog, regen the code and recompile their project so they can move on. Ideally in a one-shot way, like pushing a single button or run a single command line tool.

Because, a developer working on a project isn't interested in doing everything manually, he has a deadline to catch: if a tool can fix things, all the better, and if the tool has to make a choice it can make: pop up a dialog or enlist the tasks to perform (e.g. two tables are renamed, both have the same field layout etc.)

Unless you get these kind of things solved, the EF designer will never be what it could have been and as the EF is presented to the developer through its designer and usage patterns, it will be a tough battle to sell this to the average developer who doesn't want to waste time clicking in tiny windows to fix errors which could have been solved for him by the tool he uses, and definitely the manager of these developers doesn't want his / her team members to waste time on things like that.

But of course, your council of 5 clever people will have told you all about these kind of things by now, I'm sure ;).

re: Update Model – a Question of Identity – Part 2 of 3

VB — Tue, 29 Jul 2008 21:29:15 GMT

When I select "Update Model from DB" it shows me the pop up windows with "Add" and "Update" tables, views, SP option. When I select "Update" it throws an message:

"You cannot select or deselect....."

Hence I end up with all my DB tables again in my EDMX. If I want to update and get only 1/2 DBtables I still end up getting all tables again.

Is there any way out?????

re: Update Model – a Question of Identity – Part 2 of 3

JB — Thu, 31 Jul 2008 21:15:03 GMT

I'd just like to say thanks for the EF. I know the concept has been around for awhile, but it's nice to finally not have to use custom tools, etc.

I'd also like to point out that company's that want to compete, as well as developers that don't want to be left behind on scalable technologies would see a great benefit in having these collabrative tools. And don't share the same opinion as the board troll Frans Bouma.

Regards,

re: Update Model – a Question of Identity – Part 2 of 3

Kosher — Sat, 02 Aug 2008 12:22:08 GMT

The column and table identity issues were resolved with datasets in the past by using annotated columns and tables. But I'm sure you knew that. I like the naming (1,2,3) etc... if the name exists. Go with it =)

I hope these "entities" are modeled in the designer like datasets but with the added benefit that each "entity" is stored in a separate class file. I'm not sure if this is totally related to your issue with identities but it could provide a way to use partial classes to add a feature where two tables with colliding names are combined with partial classes. That old concept of a master schema for relating entities across catalogs, ya know? Either that or you simply allow the user to specify an "intermediate" class name that pulls the schema from both tables and allows the users to specify which table has "master" status. Of course in this intermediate table, the users might also need to annotate columns to resolve name collisions.

The DataTableAdapter is what this "Update Model" feature sounds like to me. When the underlying database model changed in the past, I would run through the wizard and choose the tables/columns that I wanted to append. That shouldn't change much.

I am new to this whole "Entity Framework" stuff. I am interested in how it addresses serialization? The old days of passing a datatable (entity) schema (with data) over a web service and then having the ability to consume the web service with visual studio's nice web service wizard made life good.

re: Update Model – a Question of Identity – Part 2 of 3

Mathias — Fri, 15 Aug 2008 16:09:36 GMT

@JB, dont think that everybody is a board troll if he doesnt pray for EF...

i also have to use EF and searching for answers to simple questions... and at this time i'm reaching the first limitations to implement all given pattern by our architect.

and we trying to use the EF domain driven, and not by a existing database...

but it seems to fail...

re: Update Model – a Question of Identity – Part 2 of 3

Günter Zöchbauer — Mon, 01 Sep 2008 22:32:46 GMT

IMHO it's mandatory to let the developer decide if the C-Side should be modified - even before the smallest change you can think of.

It's horrible to correct or remove all automatically made additions manually after each update.

Anyway, I don't understand why MS didn't ship a designer optimized for forward engineering before playing with reverse engineering.

This would be stupid simple to develop and would do the job for a vast majority of developers.

Reverse engineering is fine, but if it doesn't work fluently it's better to not use it at all or maybe just for a first import before customizing the C-Side.

The missing designer for the S-Side is a burden as well.

If I don't want to use update schema from DB due to it's destructiveness (yes, destructiveness, even if it doesn't remove anything but adding) the S-Side has to be maintained by hand.

But the EDMX-Syntax is so verbose that it's a hard to maintain using the XML-editor.

My conclusion:

The designer is absolutely useless as it is currently and maintenance of the EDMX by hand is a pain (not at least due to the combination of C-Side, S-Side and CSM in one file).

So, another one or two year waiting for a possibly usable ORM from MS.

re: Update Model – a Question of Identity – Part 2 of 3

Fred Morrison — Thu, 11 Dec 2008 11:52:23 GMT

Did you ever publish Part 3 of 3? Please post a link with either the article or the reason the last part has not yet been published.