Re: qualified to-many relationships?
Re: qualified to-many relationships?
- Subject: Re: qualified to-many relationships?
- From: Fabian Peters <email@hidden>
- Date: Sat, 09 Jul 2016 12:23:22 +0200
You can set your own ERXEditingContextDelegate and implement editingContextShouldFetchObjects(). There you can access the fetch specification and check which entity is being fetched. Then modify the qualifier to your liking. I've been using this for years in multi-tenant applications.
To set the EC delegate, implement your own ERXEC factory and set it via ERXEC.setFactory(new MyECFactory()) on framework or app initialisation.
Don't know how this will influence ERXEOControlUtilities.objectCountForToManyRelationship()…
HTH, Fabian
> Am 09.07.2016 um 11:54 schrieb OC <email@hidden>:
>
> Chuck,
>
> On 9. 7. 2016, at 6:37, Chuck Hill <email@hidden> wrote:
>
>> The answer depends on your definition of “decent”. There is nothing in EOF, and nothing that I am aware of in Wonder that will do this.
>
> Meantime I have realised one thing: the "qualifiedRecords" are current-user (i.e., session) dependent in such a way that for a given session which needs to qualify them, there will *never* be need to fetch the other records. Completely all fetches, which originate in that session, should be filtered. The demand is “a specific user should never see some records; from his point of view, the application should look like they do not exist.“
>
> Might perhaps EOF or Wonder allow some trick therefore not to implement "qualifiedRecords", but, instead, for all database operation which belong to a specific session, to _always_ filter _all_ fetches of "records" (or even better, _completely all_ fetches of the T_RECORD table, whichever way they did origin!) by a given qualifier? The only limitation is that other sessions would have to have different (or none at all) qualifiers, which prevents me to simply use a restricted entity.
>
> I tried to play a bit with DatabaseContextDelegate.databaseContextShouldFetchObjects and .databaseContextWillFireArrayFaultForGlobalID; looks like I might be able to change the fetch specifications there (which, nevertheless, Apple documentation considers worth pointing out “is very dangerous to modify”, darn).
>
> My preliminary testing though suggests I probably might need to go lower, for these delegate methods are duly called whenever the relationship fires to fetch, but do not intercept e.g., ERXEOControlUtilities.objectCountForToManyRelationship for it.
>
> Anyway, do you think the solution might be somewhere in this way, i.e., is there a trick to filter *all* fetches of a given table, if
> - all fetches from a given session should be always filtered the same way
> - fetches of the same table for another session would be filtered differently?
>
> Another way perhaps might be to
>
>> clone the model into a new, user specific EOModelGroup
>
> and add the restricting qualifier to the DBRecord entity in there? (It would not be possible to do this when the application launches; I would have to do this when user logs in into a session. I think I can get away with keeping this all the time the session exists -- if the qualifying conditions change meantime, it would be rare enough that I can say the user must logout/login to see the changes.)
>
> If none of this is (reasonably) possible, then I shall need to fall back to the originally considered way of:
>
>> To achieve this you need to:
>>
>> 1. Write the access method like yo have below, but cache the result for performance.
>> 2. Write the mutator methods (if you need them) to work on the original EOF relationship
>> 3. Modify the mutator methods of the original relationship to either invalidate or update this cache (update is faster but harder to write)
>> 4. Intercept certain EOF operations/notifications so that the cache can be updated or invalidated when EOF changes the underlying snapshots
>> I can dig the details for (4) out for you if you want to pursue this.
>
> and I would be then pretty grateful for that.
>
> Thanks a lot,
> OC
>
>> From: <webobjects-dev-bounces+chill=email@hidden> on behalf of OC <email@hidden>
>> Date: Friday, July 8, 2016 at 1:11 AM
>> To: WebObjects-Dev Mailing List <email@hidden>
>> Subject: qualified to-many relationships?
>>
>> Hi there,
>>
>> is there a way to define and use a to-many relationship, derived from a modelled one, by limiting the results by a qualifier?
>>
>> I have got an entity, say, "DBTable", whose to-many relationship "records" returns a set of eos of entity "DBRecord". That works all right.
>>
>> Now, I need to implement a "qualifiedRecords" relationship, which would work this way:
>>
>> ===
>> class DBTable ... {
>> NSArray qualifiedRecords {
>> EOQualifier qq=ERXSession.session().recordQualifier; // the qualifier depends on current user and other conditions of the current session
>> return EOQualifier.filteredArrayWithQualifier(this.records(),qq);
>> }
>> }
>> ===
>>
>> With small objects, I would use precisely the code above. Alas, my DBTables contain _lots_ of DBRecords, and thus the above implementation would get terribly slow by fetching all of them and then re-filtering them each time the relationship is accessed.
>>
>> What I need here is same behaviour functionality-wise, but at a lower level, sort of like EODatabaseDataSource's auxiliaryQualifier, but somehow bound to the particular relationship, so that
>>
>> (a) it is not needed to fetch all records -- the "qualifiedRecords" relationship would, when fired, automatically fetch only the qualified ones
>> (b) records are fetched once and then cached, just like it is with normal relationships
>> (c) I can use things like
>>
>> ERXEOControlUtilities.objectCountForToManyRelationship(sometable,"qualifiedRecords")
>>
>> etc. seamlessly, and they work as expected.
>>
>> Is there a way to do this at all? Perhaps I am just blind, but I cannot find any decent solution :/
>>
>> Thanks and all the best,
>> 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