Chuck,
On 9. 7. 2016, at 11:54, OC <o...@ocs.cz> wrote:
> 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?
Well, as you probably have seen at the first look, this was one of my
(frequent) not-so-bright ideas. It seems e.g., the dbcontext delegate can do it
all right and it works excellently: whichever thing gets fetched from given
entity on behalf of a given user gets perfectly filtered.
> The only limitation is that other sessions would have to have different (or
> none at all) qualifiers
You know the result: if another user wants the data later, they, of course, are
not fetched in his behalf; instead, they come from shared caches, already
(improperly) filtered for the original user, whose request did fetch. Oops.
I suppose, even if I managed to
>> clone the model into a new, user specific EOModelGroup
>
> and add the restricting qualifier to the DBRecord entity in there?
it would lead to the same problem: presumably the entity restricting qualifier
would be used fetch-time; and the next time another user wants the data, he
would get cached ones, which means, for him, wrong list.
Thus I am afraid indeed
> none of this is (reasonably) possible
and truly
> 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.
If you can spare a moment, let me please know.
Might perhaps ERXEnterpriseObjectArrayCache help here? From its documentation
it sort of seems it might perhaps be listening to those notifications to keep
up to date automagically, but I have never used the thing and am not sure by
far I understand the documentation...
Thanks a big lot!
All the best,
OC
>> From: <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on behalf
>> of OC <o...@ocs.cz>
>> Date: Friday, July 8, 2016 at 1:11 AM
>> To: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com>
>> 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 (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/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
