Re: Model Cloning
Re: Model Cloning
- Subject: Re: Model Cloning
- From: Susanne Schneider <email@hidden>
- Date: Thu, 12 Jul 2007 14:08:54 +0200
Hi Andrew,
no, we copying the models as objects in jave, like:
1) create new model B
2) go through all entities from model A
3) for each entity A1 create new entity B1
4) copy all properties from A1 to B1 (this is a bit tricky for relations)
5) add entity B1 to model B
6) add model B to default or new model group
We never listens to EntityLoadedNotification, so we had no problems
there. Instead we listen to "ModelAddedNotification" to reset the
database connection.
This is done mostly at startup. For model changes during the lifetime of
the application we reload the affected model. The last thing we had to
manage was the reset of class-descriptions for all eos if the
corresponding model changed. We did this be register our subclass of
EOEditingContext as a listener for the ModelAddedNotification and then
resets all class descriptions for the effected eos. Besides occasional
NullpointerExceptions in the call of ec.registeredObjects() this seems
to work.
In the beginning we tried to store the created models in the database as
a property list, but there was too much problems with models and
entities created from that (no public constructors with property lists
as far as I remember). So we abandoned that idea and returned to pure
object handling and template models.
Regards,
Susanne
Andrew Lindesay schrieb:
Hallo Susanne;
This is where a one-way replica of a database is used for batch
processing. I think the problem I was having was that the
"EntityLoadedNotification"-s were flying around and possibly making the
wrong associations with models. If I fully load the models first then
this seems to stop being a problem. I'm interested; do you encode the
EOEntity from model A into a property list and then fiddle the property
list and then deserialise it into the second model?
cheers.
we are hassling with models here a lot, but with a mix of the
procedure you discribed and the one of Chuck. Instead of reloading
model B we are copying model A to a new model B with renaming the
entities while copying. For normal work both models are put into the
default model group. For rare occasions we need real duplicates (same
entity names) to a different database scheme and then put the
duplicate models into a separate model group.
Were you just curious or do you have a concrete problem with this?
...
I'm doing;
1) fully-load model A
2) set the JDBC config for model A
3) re-load clone model into a new EOModel called B from A's URL
4) rename B's entities and the model with a suffix "RO".
5) make B's entities read-only
6) insert B into the default model group
This allows me to force some database queries to a separate server
as long as there is no "crossing-of-the-models". Has anybody else
tried something like this?
___
Andrew Lindesay
technology : www.lindesay.co.nz
business : www.silvereye.co.nz
--
Susanne Schneider
Coordinator secuSuite Development
iAS interActive Systems GmbH
Dieffenbachstraße 33 c, D-10967 Berlin
fon +49(0)30 69 00 42 - 05
fax +49(0)30 69 00 42 - 10
mail email@hidden
web http://www.interActive-Systems.de
----------------------------------------------------
Geschäftsführer: Dr. Marko Reschke, Thomas Fritzsche
Sitz der Gesellschaft: Berlin
Amtsgericht Berlin Charlottenburg, HRB 106103B
----------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden