Hi Markus,

I made a presentation 
http://www.slideshare.net/wocommunity/filtering-data-with-d2w

It could help you as well. 

Our need was to manage a multi-tenants database so it was close of your 
description: a user belongs to a company and can see only the data linked to 
the company. 

Best,

Philippe

> On 22 juil. 2016, at 09:49, Chuck Hill <[email protected]> wrote:
> 
> EOEditingContext.Delegate.editingContextShouldFetchObjects is what I was 
> going to suggest too.  Get the session to stash the region details in a 
> thread local in awake and remove in sleep.
>  
> I think it was OC that tried this before, but he wanted it to also affect 
> firing a to-many relationship fault, IIRC.
>  
> From: <[email protected] 
> <mailto:[email protected]>> on 
> behalf of Ramsey Gurley <[email protected] 
> <mailto:[email protected]>>
> Date: Friday, July 22, 2016 at 9:43 AM
> To: Markus Ruggiero <[email protected] 
> <mailto:[email protected]>>
> Cc: "[email protected] <mailto:[email protected]>" 
> <[email protected] <mailto:[email protected]>>
> Subject: Re: Looking for strategy
>  
> This may be possible using 
> EOEditingContext.Delegate.editingContextShouldFetchObjects to modify fetch 
> specs in flight. I vaguely remember someone saying they tried that and it 
> didn’t work out.
>  
> If it isn’t possible there, then perhaps it would be possible to produce an 
> EC subclass that appends the proper qualifier to fetches in 
> objectsWithFetchSpecification, then ERXEC.setFactory to produce your subclass 
> when the application starts.
>  
> You’ll probably need QualifierTraversal, ERDQualifierTraversal, or 
> ERXQualifierTraversal for qualifier modifications, since the qualifier you 
> need to modify might be deeply nested. Keeping track of which entity the 
> attribute key applies to might be difficult since the qualifier has no link 
> to it.
>  
> On Jul 22, 2016, at 7:27 AM, Markus Ruggiero <[email protected] 
> <mailto:[email protected]>> wrote:
>  
> Hi Theodore,
> thanks for the tip, will look into it. However I do have some non-D2W 
> queries, primarily related to direct action batch processing and things. 
> There I'd have to not forget to add the Region query criteria in code 
> everywhere today (and tomorrow, and also tell my co-workers). The D2W 
> approach is great as it is kind of global (at least in D2W space). Even more 
> global would be someting I could plug into the lower levels of EOF that would 
> add the criteria unconditionally, no matter D2W or "handcrafted" fetch spec.
> ---markus---
> On 22.07.2016, at 15:57, Theodore Petrosky <[email protected] 
> <mailto:[email protected]>> wrote:
> Does the ERDQueryDataSourceDelegateInterface help you here?
> https://wiki.wocommunity.org/display/documentation/D2W+Flow+Control 
> <https://wiki.wocommunity.org/display/documentation/D2W+Flow+Control>
> On Jul 22, 2016, at 9:43 AM, Markus Ruggiero <[email protected] 
> <mailto:[email protected]>> wrote:
> Folks,
> My app has some 50+ entities. About 2 third of them have data that is 
> specfiic to a Region, the rest of the entities is Region agnostic.
> Example:
> Article toMany Descriptions
> Article is Region agnostic but can have Region specific descriptions, thus 
> Descriptions have an optional toOne to Region
> Background: A user of the app is assigned a Region during login. He must be 
> allowed to only see Region agnostic data or objects that are assigned to the 
> current Region only.
> What I want is a generic way to have something like the following SQL 
> generated by the Frameworks:
> select * from article where some_selection_criteria;  -- no region reference
> select * from description where some_selection_criteria (AND REGION_ID IS 
> NULL OR REGION_ID = A_GIVEN_REGION_ID);
> This must also function for queries like: select all articles that have 
> description for region XYZ.
> I am thinking along the following lines: attach some code deep in the 
> framework to add such a restricting clause to where for every select for any 
> region specific table.
> How would I do this? Any better ideas?
> Thanks a lot
> ---markus---
> _______________________________________________
> 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/tedpet5%40yahoo.com 
> <https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.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/rgurley%40smarthealth.com
>  
> <https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.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/chill%40gevityinc.com 
> <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/prabier%40icloud.com 
> <https://lists.apple.com/mailman/options/webobjects-dev/prabier%40icloud.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])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to