|
On 2014-11-25, 3:22 PM, "OC" wrote:
Oh, by the way...
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.
Do they have to be in the same relationship? Could you have two, one for the hard-coded and one for the normal objects? They could both share a common interface. Then you could use custom attribute types to create a POJO based on the attribute value
for the hard coded ones. I don’t think you can easily use a relationship (as opposed to an attribute) as EOF will want it to have GID. So code like
public ITemplate printTemplate() {
return builtInTemplateFromAttribute() != null ? builtInTemplateFromAttribute() : userCreatedTemplate();
}
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
Well, that would save you some of the headache you have been dealing with today in terms of PK duplication. You would have to deal with unique constraint violations, but not GID craziness.
(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 :)
My idea above is the best I have at the moment. Maybe it will inspire something better from someone else.
Thanks again and all the best,
OC
Always a pleasure.
Chuck
|