Re: Horizontal inheritance to splitting big database tables to speed up?
Re: Horizontal inheritance to splitting big database tables to speed up?
- Subject: Re: Horizontal inheritance to splitting big database tables to speed up?
- From: "Morris, Mark" <email@hidden>
- Date: Mon, 11 Jul 2016 15:34:49 +0000
- Thread-topic: Horizontal inheritance to splitting big database tables to speed up?
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 <email@hidden> wrote:
>
> Mark,
>
> On 11. 7. 2016, at 7:03, "Morris, Mark" <email@hidden> 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 <email@hidden> 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 <email@hidden> wrote:
>>>
>>>> Thinking about
>>>>
>>>> On 9. 7. 2016, at 12:13, OC <email@hidden> 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 (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden