Chuck, first, one quick question -- on one server, 30-odd objects simply disappeared, just like that. At one moment, I've started getting "databaseContextFailedToFetchObject" callbacks, and when I checked, the offending objects indeed did not exist -- whilst the FKs from other objects did (and caused those callbacks when relationships fired).
Neither my logs nor audits seem to give any hint what the darn might have caused the problem. Can (far as anyone knows) any combination of FrontBase locks[*] and Remote Synchronizer lead to deletion (not wrong contents, but outright disappearance) of a number of table rows?!? [*] note: it was in an older version of my application, which far as I know without being able to confirm through FBManager run serialized/pessimistic, and which did *not* yet contain the deleteObject fix for same-PK insertion fail you have recommended (so it could hardly cause it even if I messed something up and deleteWrongObjects instead). Completely weird. The probability the missing objects were deleted explicitly through my code is minor (all such things are logged out and audited in database both, and a bug which would render both log and audit inoperable is of course possible, but extremely improbable). Also, I went through all cascade deletions and owning to-manys in my models, and none of them has the offending entity for destination (nevertheless I've found a couple of highly suspect cascades with other entities to be thoroughly examined when I have time to :P) Well back to the subject... On 26. 11. 2014, at 0:57, Chuck Hill <[email protected]> wrote: > On 2014-11-25, 3:22 PM, "OC" wrote: > >> 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(); > } This can be done (and perhaps it might truly be the best course in the long run), but the problem is that those “print templates“ themselves are non-atomic; they are made from a network of objects, all of which have their own relationships -- amongst them, and to normal EOs “outside” the “static” part both. It would be possible to implement it all manually, so to speak -- but it would be rather lots of work, compared with what one gets “for free” if all those objects and their relationships are simply set up in Modeller. Well of course, given the amount of problems that approach generates, the “for free” part sounds just a bit on the naïve side, does it not? :P (Just lately I've bumped into another: when those objects are sync'd with the database, it's possible another instance is already using them; when the first one changes the db contents, hilarity ensues again.) Hmph. I guess I'll try to find some solution with pure in-memory, not-EO objects indeed... perhaps I'll rig some hackery to be able to model such objects and to generate all the "if (I am an EO) return relationshipValue(foo); else return propertyValue(foo)" (semi-)automagically... (There was another problem with non-EO objects: shared API, for it was next to impossible to share API betw. two different classes which are not one subclass of another in Java. Now when I've switched to Groovy and when Groovy has full-fledged traits, hopefully this can be very easily overcome :)) Thanks a lot, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
