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<mailto: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<mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com>> on behalf of OC <o...@ocs.cz<mailto:o...@ocs.cz>> Date: Friday, July 8, 2016 at 1:11 AM To: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com<mailto: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<mailto: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<mailto:ch...@gevityinc.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com<mailto: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<mailto: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
