What Tim suggests is definitely the most straightforward way to do it. If you 
are looking for something more global in EOF, I see

databaseContextShouldFetchObjects

On EODatabaseContext.Delegate and

editingContextShouldFetchObjects

on EOEditingContext.Delegate. 

You might be able to modify the qualifier on the fetchspec there. I've kinda 
planned on trying this myself with my authorization framework, since I'd like 
to add qualifiers to all fetches based on logged in users. Not sure how well 
that will work, but it might be worth exploring.

Ramsey

On Apr 10, 2013, at 12:03 PM, Tim Worman wrote:

> Hello Markus:
> 
> You would add a QueryDataSourceDelegate class to your D2W app that implements 
> ERDQueryDataSourceDelegateInterface.
> 
> http://wiki.wocommunity.org/display/documentation/D2W+Flow+Control
> 
> Then, all your D2W code would automatically use that any time the respective 
> entity was fetched. You could have a quartz job in the app that used standard 
> fetch methods to run the tasks on the items where ! isVisible.
> 
> Tim
> UCLA GSE&IS
> 
> On Apr 10, 2013, at 11:21 AM, Markus Ruggiero <[email protected]> 
> wrote:
> 
>> 
>> On 10.04.2013, at 19:50, Chuck Hill <[email protected]> wrote:
>> 
>>> 
>>> On 2013-04-10, at 10:29 AM, Markus Ruggiero wrote:
>>> 
>>>> Thanks for all your suggestions so far, but I think none is what can 
>>>> really help me. Let me explain a bit more.
>>>> 
>>>> Cleanup does not only mean delete the Product from the database but first 
>>>> I have to build an XML structure that contains the product data and 
>>>> related data from several to-one and to-many relationships. This XML is 
>>>> then sent to a remote application. Only when that application (not under 
>>>> my control) agrees I am allowed to finally remove that Product. 
>>>> 
>>>> - Having a clone of the Product entity without the restricting qualifier 
>>>> is therefore not such a good idea, as I need to maintain all the 
>>>> relationships from and to that entity. Nightmare!
>>>> 
>>>> - Just removing the restricting qualifier is an option, but then there are 
>>>> dozens of locations throughout the app where products are fetched, some 
>>>> through D2WQueryPage, others explicitly for populating selection lists, 
>>>> yet others when generating XML data. Nightmare!
>>>> 
>>>> - Having a second instance of the app with a property set to remove the 
>>>> restricting qualifier might be a way to go, but some cleanup related 
>>>> actions must be explicitly done by an interactive user. What instance 
>>>> should a user connect to? Depending on what he/she wants to do, it's the 
>>>> one where the cleanup works or not.
>>> 
>>> You would give them different names, ProductManager.woa and 
>>> ProductCleanup.woa
>>> 
>>> 
>>>> So basically my question still is, how do I circumvent that restricting 
>>>> qualifier? Might there be a way to do this with a delegate somewhere down 
>>>> the EOF stack? At what point in processing is the final qualifier built? I 
>>>> could set a delegate and if needed remove the restriction from the 
>>>> generated SQL statement. But how and where would I do this? Never had to 
>>>> go that deep into advanced EOF land.
>>> 
>>> I don't think that is going to leave you in a happy place.  You could 
>>> create a super-class of Product with visible='N' as the qualifier.  I am 
>>> not sure if that would work for you.  That qualifier is really intended for 
>>> use with EOF inheritance and you are bending it to something it was not 
>>> intended for.  That is why EOF is not allowing you to change it - it would 
>>> change inheritance hierarchies.  A better choice might be to apply this in 
>>> code though centralized fetching methods.
>>> 
>>> 
>>> Chuck
>>> 
>> 
>> Thanks (or not so) Chuck, I feared something like this. Then let me ask a 
>> related question: how would I implement the visible='Y' in a ERD2WQueryPage? 
>> The user should never see the attribute (so it won't be in 
>> displayPropertyKeys) but it must be used for qualifying in addition to any 
>> other qualifications the user makes on the page. 
>> 
>> ---markus---
>> 
>>> 
>>> 
>>>> PS the IllegalArgumentException mentioned in my first posting was due to 
>>>> rawRows bringing back all the attribute names in upper case but the id 
>>>> attribute is in lower case. So this has been resolved, but even then I 
>>>> only get faults that are later on resolved against the database - again 
>>>> including the restricting qualifier. Even objectsWithPrimaryKey() uses the 
>>>> qualifier.
>>>> 
>>>> 
>>>> On 10.04.2013, at 13:52, Markus Ruggiero <[email protected]> wrote:
>>>> 
>>>>> Folks,
>>>>> 
>>>>> I have an entity Product with an attribute isVisible. Throughout my 
>>>>> application I only work with products that are visible. So I have 
>>>>> specified a qualifier visible='Y' right in the model. This qualifier is 
>>>>> automatically AND-added to each and every query agains Product. Fine, I 
>>>>> am happy with this.
>>>>> 
>>>>> Now the customer needs an automatic cleanup function. This function must 
>>>>> fetch products that are not visible. Cleanup requires more than just 
>>>>> deletion from the database. I cannot do the cleanup with raw rows, I do 
>>>>> need real EOs. How can I override that model qualifier? When fetching raw 
>>>>> rows I do get the data but I was not able to convert the dictionaries to 
>>>>> EOs. The ID attribute is in the dictionary (which is the PK) but I get an 
>>>>> IllegalArgumentException telling me "does not contain primary key 
>>>>> information for entity Product"
>>>>> 
>>>>> This is the code I use (maybe there is a problem there)
>>>>> 
>>>>> NSMutableArray<Product> products = new NSMutableArray<Product>();
>>>>> NSArray<NSDictionary<String, Object>> rawRows = 
>>>>> EOUtilities.rawRowsForSQL( ec, "ec2", "select * from PRODUCT where 
>>>>> visible = 'N' ", null);
>>>>> for (NSDictionary row : rawRows) {
>>>>>   Product prod = (Product) EOUtilities.objectFromRawRow( ec, 
>>>>> Product.ENTITY_NAME, row );
>>>>>   products.addObject( prod );
>>>>> }
>>>>> 
>>>>> Thanks for your help
>>>>> ---markus---
>>>>> 
>>>>> _______________________________________________
>>>>> 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/mailinglists%40kataputt.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/chill%40global-village.net
>>>> 
>>>> This email sent to [email protected]
>>> 
>>> -- 
>>> Chuck Hill             
>>> Executive Managing Partner, VP Development and Technical Services
>>> 
>>> Practical WebObjects - for developers who want to increase their overall 
>>> knowledge of WebObjects or who are trying to solve specific problems.    
>>> http://www.global-village.net/gvc/practical_webobjects
>>> 
>>> Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest 
>>> Growing Companies in B.C! 
>>> Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of 
>>> Canada’s Fastest-Growing Companies by PROFIT Magazine!
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> 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%40thetimmy.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/rgurley%40smarthealth.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]

Reply via email to