I see.
Can you please nudge how would one do the „EOF stack per session“ (or per a
selected number of sessions, but not all of them) magic? I guess I should know,
but my old dumb brains does not seem to co-operate much at the moment :)
Thanks a lot,
OC
On 11. 7. 2016, at 6:47, Chuck Hill <ch...@gevityinc.com> wrote:
> This is why you want an EOF stack per session. This the only way to have
> very different configurations per session. Without that, I don’t think that
> ERXEnterpriseObjectArrayCache is going to help you much. You need to
> configure an isolated EOF stack per session to show that session just the
> data that is appropriate to it.
>
> Chuck
>
> From: OC <o...@ocs.cz>
> Date: Sunday, July 10, 2016 at 5:23 AM
> To: Chuck Hill <ch...@gevityinc.com>
> Cc: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com>
> Subject: Re: qualified to-many relationships?
>
> 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
