Well... I have re-written my test code completely. Alas there does not seem to be a delegate method which would allow to select the target entity dynamically based on the source EO :( In fact, I did not succeed to get subEntityForEntity at all, whatever I tried (nor relationshipFailedToLookupDestinationWithName); and classForObjectWithGlobalID gets called all right, but only _after_ fetch, not before, where it would help.
Oh, sigh. Am I overlooking some hidden gem of a WOnder or EOF delegate, through which one _could_ set the target entity for a relationship based on the source EO, before EOF tries to fetch? Thanks and all the best, OC On 10. 7. 2016, at 21:25, OC <o...@ocs.cz> wrote: > Thinking about > > On 9. 7. 2016, at 12:13, OC <o...@ocs.cz> wrote: > >> For one, it would mean each DBTable eo would have its "records" relationship >> leading into another target DBRecordXX entity; I am not sure whether this >> can be modelled at all? > > actually it would help a lot even without special FrontBase support. > > My current setup is the very primitive > > - DBTable entity, it has a :N relationship "records" into DBRecord > - DBRecord entity, which contains a FK into DBTable which models an inverse > :1 relationship "table" into DBTable. > > A setup we all did a zillion times. > > Now I wonder, might perhaps a horizontal inheritance help me to split those > DBRecords? Let us assume that > > (a) I add a "tableType" numeric column to DBTable; there would be N distinct > table types > (b) I model N separate DBRecord1, DBRecord2, ..., DBRecordN entities, all of > them children of DBRecord (which itself would become abstract) > (c) each of them would be linked to a separate SQL table > > At the database level, this definitely would work well. What I can't see, how > to process this at the model and EOF levels? > > - I cannot model a relationship to “different entity for each row”; > therefore, the target of the "records" relationship of DBTable would still > have to be the (abstract) DBRecord; > - runtime, I would have tell _somehow_ to the EOF that if it is about to fire > "records" of a DBTable object, it should fetch them from the > ["DBRecord%@",table.tableType] entity instead of from DBRecord -- the > subEntityForEntity delegate method comes to mind > - when adding new records, I would simply use > EOUtilities.createAndInsertInstance with appropriate entity name (e.g., > "DBRecord33"). > > Should such a thing work, or am I in for a nasty surprise? I have actually > tried, but either it should not work, or I messed up something else; instead > of the desired result (or some intelligible error report) I am getting a very > weird “Cannot register the database context for the model Shared” (which is > *not* the model which contains my abstract/inherited entities). And, my > subEntityForEntity delegate method is never called. > > Thanks a lot, > OC > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz > > This email sent to o...@ocs.cz _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
