P.S.
Well I _am_ sort of at the slow side today.
I guess this might bring nasty problems with EOs *not* synchronized, right? The
net effect would be essentially the same as if each session run in its own
instance, or am I wrong?
Thanks again,
OC
On 11. 7. 2016, at 13:12, OC <o...@ocs.cz> wrote:
> 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/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
