Fabian, On 9. 7. 2016, at 12:23, Fabian Peters <[email protected]> wrote:
> You can set your own ERXEditingContextDelegate and implement > editingContextShouldFetchObjects(). There you can access the fetch > specification and check which entity is being fetched. Then modify the > qualifier to your liking. I've been using this for years in multi-tenant > applications. Thanks! What's the difference from DatabaseContextDelegate.databaseContextShouldFetchObjects? That here, the qualifier can be changed safely, whilst in the DatabaseContextDelegate it would be dangerous? > To set the EC delegate, implement your own ERXEC factory and set it via > ERXEC.setFactory(new MyECFactory()) on framework or app initialisation. > Don't know how this will influence > ERXEOControlUtilities.objectCountForToManyRelationship()… I have just tested, and it seems it does not, just like the DatabaseContextDelegate. Thanks again, OC >> Am 09.07.2016 um 11:54 schrieb OC <[email protected]>: >> >> Chuck, >> >> On 9. 7. 2016, at 6:37, Chuck Hill <[email protected]> wrote: >> >>> The answer depends on your definition of “decent”. There is nothing in >>> EOF, and nothing that I am aware of in Wonder that will do this. >> >> 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? The only limitation is that other >> sessions would have to have different (or none at all) qualifiers, which >> prevents me to simply use a restricted entity. >> >> I tried to play a bit with >> DatabaseContextDelegate.databaseContextShouldFetchObjects and >> .databaseContextWillFireArrayFaultForGlobalID; looks like I might be able to >> change the fetch specifications there (which, nevertheless, Apple >> documentation considers worth pointing out “is very dangerous to modify”, >> darn). >> >> My preliminary testing though suggests I probably might need to go lower, >> for these delegate methods are duly called whenever the relationship fires >> to fetch, but do not intercept e.g., >> ERXEOControlUtilities.objectCountForToManyRelationship for it. >> >> Anyway, do you think the solution might be somewhere in this way, i.e., is >> there a trick to filter *all* fetches of a given table, if >> - all fetches from a given session should be always filtered the same way >> - fetches of the same table for another session would be filtered >> differently? >> >> Another way perhaps might be to >> >>> clone the model into a new, user specific EOModelGroup >> >> and add the restricting qualifier to the DBRecord entity in there? (It would >> not be possible to do this when the application launches; I would have to do >> this when user logs in into a session. I think I can get away with keeping >> this all the time the session exists -- if the qualifying conditions change >> meantime, it would be rare enough that I can say the user must logout/login >> to see the changes.) >> >> If none of this is (reasonably) possible, then 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. >> >> Thanks a lot, >> OC >> >>> From: <[email protected]> on >>> behalf of OC <[email protected]> >>> Date: Friday, July 8, 2016 at 1:11 AM >>> To: WebObjects-Dev Mailing List <[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]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com >>> >>> This email sent to [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/lists.fabian%40e-lumo.com >> >> This email sent to [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]
