Entity Framework Synchronising Models

  • Thread starter Thread starter Chris Kennedy
  • Start date Start date
C

Chris Kennedy

I would like to use the EF to do better modelling than just table to type
mapping. For instance I want entities that map across several tables. One
potential problem is keeping the EDM synchronised across developers. If a
developer makes a change to a custom class on one machine and another makes
a similar change on their machine one change could overwrite the other. With
table to type it's easier as their is always a one to one mapping with the
database. Can anyone suggest any approaches. This is what I will be looking
at:

1. Lock the EDM in VSS source control (I could see this being a problem)
2. Some kind of merge approach - a little like subversion - is there a way
to do this?
3. Use EDM's in a more modular way to reduce locking

Does anyone have any experience of this. It's a fairly broad problem and not
just EF. Regards, Chris.
 
Chris said:
I would like to use the EF to do better modelling than just table to
type mapping. For instance I want entities that map across several
tables. One potential problem is keeping the EDM synchronised across
developers. If a developer makes a change to a custom class on one
machine and another makes a similar change on their machine one change
could overwrite the other. With table to type it's easier as their is
always a one to one mapping with the database. Can anyone suggest any
approaches. This is what I will be looking at:

1. Lock the EDM in VSS source control (I could see this being a problem)
2. Some kind of merge approach - a little like subversion - is there a
way to do this?
3. Use EDM's in a more modular way to reduce locking

Does anyone have any experience of this. It's a fairly broad problem and
not just EF. Regards, Chris.
Click to expand...

The red flag should be: why are two developers making changes to the
same entity definition? That suggests badly scheduled work. Look at it
as a db application: if two users edit the same customer record, who
will have their work be tossed out due to the optimistic concurrency?

I.o.w.: schedule your work better: if entity A, B and C have to be
changed, assign a person to do that, and let others make other changes.

FB


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
I see where you are coming from but the way we work. Is that everyone has a
copy of the db on their local machine. They make changes, put it in a script
and those changes are ran on the pre-prod server and a build etc is done to
see if anything is broken as a result.

To fit in with this workflow the EF can get out of synch as different
developers make their own local changes. It would be nice to let them make
their own changes and somehow merge the EF or something....
 
Chris said:
I see where you are coming from but the way we work. Is that everyone
has a copy of the db on their local machine. They make changes, put it
in a script and those changes are ran on the pre-prod server and a build
etc is done to see if anything is broken as a result.

To fit in with this workflow the EF can get out of synch as different
developers make their own local changes. It would be nice to let them
make their own changes and somehow merge the EF or something....
Click to expand...

I understand your way of working, it's how a lot of teams work in large
systems. The thing is though: you have to realize that this way of
working with distributed definitions relies heavily on a solid merging
strategy which never leads to ambiguity nor merge conflicts which aren't
solveable. It's precisely those things which can and should be avoided.
For example, if you make the subsystems everyone works on more atomic,
i.e. less overlap for the changes, you limit the area where merge
conflicts will arise.

With code, one could solve merge conflicts in a merge application by
selecting left or right etc. The problem with XML based data and
definition files in general is that a choice whether change A or B
should be taken in the case of a merge conflict has consequences for the
elements relying on A or B: if you pick A, you also have to pick the
elements relying on A being there. This isn't always that obvious. If
you DONT pick those changes as well, you get corrupted files as a
result: they might be correct XML, but the data inside makes no sense.

FB


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
Back
Top