OC, Sorry, I did this in a project 10 years and a few laptops ago, and the code is archived off somewhere. I don’t remember if I hooked in at the adaptor level or if I somehow used EOSQLExpression….
— Mark > On Jul 11, 2016, at 6:13 AM, OC <o...@ocs.cz> wrote: > > Mark, > > On 11. 7. 2016, at 7:03, "Morris, Mark" <mark.mor...@experian.com> wrote: > >> I don’t know that there’s a way to do this. >> >> What I did before was to intercept at the SQL-generation stage and change >> the table names based on a session variable value. > > I see. Might I perhaps ask which hooks did you employ, just in case they > might prove valuable for my problem, too? > > Thanks a lot, > OC > >> This was not for performance in my case, it was because a horrible student >> information system at a school system I was at duplicated every table for >> every school in the system, with a school-specific suffix added to the table >> name, and I was hiding that complexity from the rest of the app development. >> I could see how something like this might be used in an extreme case to >> address performance issues, but it certainly depends on your situation. >> >> — Mark >> >>> On Jul 10, 2016, at 7:20 PM, OC <o...@ocs.cz> wrote: >>> >>> 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
