Chuck, On 11. 7. 2016, at 6:49, Chuck Hill <ch...@gevityinc.com> wrote:
> IIRC those methods are for determining the correct entity/class to > instantiate based on the row values fetched. AKA These are not the droids > you are looking for. Indeed, looks like the Force is not with me. No other (reasonably simple) way you would know of to hook into EOF to obtain the desired effect, i.e., to be able to determine the target entity _before_ a fetch? Thanks again, OC > From: <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on behalf > of OC <o...@ocs.cz> > Date: Sunday, July 10, 2016 at 5:20 PM > To: Mark Morris <mark.mor...@experian.com> > Cc: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com> > Subject: Re: Horizontal inheritance to splitting big database tables to speed > up? > > 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/chill%40gevityinc.com > > This email sent to ch...@gevityinc.com _______________________________________________ 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
