Yes, it makes it behave as if each was in its own instance. Are you dependent on running in a single instance?
You need to create a new EOObjectStoreCoordinator for each session/group and pass it to the EOEditingContext constructor. As you want to mutate the model, you will also need to create a new EOModelGroup and clone the models into it. I forget at the momemt where this new group gets setModelGroup() in. You also need to ensure that none of your code or called Wonder code etc uses EOModelGroup.defaultGroup() Chuck From: OC <[email protected]> Date: Monday, July 11, 2016 at 5:25 AM To: Chuck Hill <[email protected]> Cc: WebObjects-Dev Mailing List <[email protected]> Subject: Re: qualified to-many relationships? 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Date: Sunday, July 10, 2016 at 5:23 AM To: Chuck Hill <[email protected]<mailto:[email protected]>> Cc: WebObjects-Dev Mailing List <[email protected]<mailto:[email protected]>> Subject: Re: qualified to-many relationships? Chuck, On 9. 7. 2016, at 11:54, OC <[email protected]<mailto:[email protected]>> 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: <[email protected]<mailto:[email protected]>> on behalf of OC <[email protected]<mailto:[email protected]>> Date: Friday, July 8, 2016 at 1:11 AM To: WebObjects-Dev Mailing List <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to [email protected]<mailto:[email protected]> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz This email sent to [email protected]<mailto:[email protected]> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz This email sent to [email protected]<mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
