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: OC <email@hidden>
- Date: Mon, 11 Jul 2016 13:10:25 +0200
Chuck,
On 11. 7. 2016, at 6:49, Chuck Hill <email@hidden> 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=email@hidden> on behalf of OC <email@hidden>
> Date: Sunday, July 10, 2016 at 5:20 PM
> To: Mark Morris <email@hidden>
> Cc: WebObjects-Dev Mailing List <email@hidden>
> 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 <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
_______________________________________________
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