"Static" objects in EC (was: multi-instance sync woes)
"Static" objects in EC (was: multi-instance sync woes)
- Subject: "Static" objects in EC (was: multi-instance sync woes)
- From: OC <email@hidden>
- Date: Wed, 26 Nov 2014 00:22:54 +0100
Oh, by the way...
On 26. 11. 2014, at 0:03, OC <email@hidden> wrote:
> It is an ancient and rather convoluted code whose purpose was more-or-less to simulate a shared editing context, which -- can't recall clearly now -- either was buggy then, or there was some other problem with the thing.
... I have checked the project documentation, and seems the "other problem" were relationships.
There are objects of a given entity; most of them have normal lifecycle like a normal EO, but some of them are "static": conceptually, they should be hard-coded in the application.
Something like, hmmm, say the app manages print templates. There are a couple of hard-coded ones, and the user can create his own ones as well.
All the objects -- "static" and normal as well -- need to go to relationships, which (far as I understand EOF and unless I'm missing something) prevents not just the shared EC, but also the otherwise-best solution of having these "static" objects in-memory only, without actually storing them in the DB.
The current PK-based solution is ugly, but to be frank, I can't see much better one. Well, instead of fixed PKs I can use an identifier, which will get rid of all the ugly fixed-PK code, but still
(a) the "static" objects will have to be stored in the database
(b) thus the application, when launched, must go through the drudgery of syncing the desired state (as defined by some plists in the app bundle) and what's stored in the DB
(c) and, although it would be best if all the "static" objects were shared (but for the (b) above, they are R/O), it does not seem possible, and each EC is bound to contain a copy of them...
I don't like this, but I can't see a better approach. If you can, I'll be pretty grateful as soon as the refactoring time comes :)
Thanks again and all the best,
OC
_______________________________________________
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