Hi Samuel,

Cool beans. Thanks for playing it forward :-)

Glad you like the “identity qualifier” concept.

It’s one of those things that drive most of nuts in the beginning… so much so 
that we want to expose our privates.

So instead of exposing your private primary-key (and violating one of the 10 
commandments) you can use the identity qualifier instead.

your method names look great but in one of the comments it says you are passing 
an "array of identity qualifiers” - I know what you meant but really it is an 
"array of EOs" which you internally create identity qualifiers for.

Good stuff and thanks for sharing. 
AARON ROSENZWEIG / Chat 'n Bike
e:  [email protected]  t:  (301) 956-2319             
        

On May 16, 2016, at 12:59 PM, Samuel Pelletier <[email protected]> wrote:

> Thank you Aaron,
> 
> I've wondered for a long time on the best way to achieve that!
> 
> I'm preparing a pull request to add some methods in ERXQ and ERXKey to help 
> using that...
> 
> In ERXQ (based on your code):
> 
> /**
> * Return an identity qualifier to use with ERXExistsQualifier for example
> public static EOQualifier is(ERXGenericRecord value) {
> /**
>  * Return a OR qualifier of identity qualifier using each value from the 
> param array
> public static EOQualifier isIn(NSArray<? extends ERXGenericRecord> 
> valueArray) {
> 
> in ERXKey:
> /**
> * Uses ERXExistsQualifier with an array of identity qualifiers to build a 
> qualifier that 
> * returns true if at least one the objects specified is found in the to many 
> relationship 
> * represented by this key.
> public ERXExistsQualifier containsAnyOfTheseObjects(NSArray<? extends 
> ERXGenericRecord> valueArray) {
> 
> I also added shortcuts to create an ERXExistsQualifier that uses IN:
> public ERXExistsQualifier containsAnyObjectSatisfyingUsingIn(EOQualifier 
> qualifier) {
> public ERXNotQualifier doesNotContainsAnyObjectSatisfyingUsingIn(EOQualifier 
> qualifier) {
> 
> I'm open to comments on the methods names before sending the pull request.
> 
> Samuel
> 
> 
> 
>> Le 12 mai 2016 à 23:28, Aaron Rosenzweig <[email protected]> a écrit :
>> 
>> Hi Paul and everyone,
>> 
>> What you did is ok - not bad but since you are asking for more here you go.
>> 
>> It is probably a bad idea to model the back relationship from “Role -> 
>> Users” as one role could be used by thousands of users. You don’t want to 
>> fault all those people in when you “addToBothSidesOfRelationshipWithKey().” 
>> That said you *could* model it and be careful to not add to both sides and 
>> be careful never to trip that fault. You could also model it as a “non 
>> class” invisible property. If you had this relationship you could do the 
>> following.
>> 
>> EOQualifier noticeQualifierForUser = 
>> Notice.ROLES.dot(Role.USERS).containsAnyObjectSatisfying(loggedInUser.identityQualifier())
>> 
>> You can use that one qualifier to fetch all the Notices for your user. 
>> 
>> The “identityQualifier()” could be defined in your EO like so:
>> 
>>      public EOQualifier identityQualifier() {
>>              final EOEntity entity = entity();
>>              final NSDictionary<String, Object> primaryKeyDictionary = 
>> primaryKeyDictionary(false /* inTransaction */);
>>              final EOQualifier thatAreThis = 
>> entity.qualifierForPrimaryKey(primaryKeyDictionary);
>>              return thatAreThis;
>>      }
>> 
>> Note: “containsAnyObjectSatisfying()” is a thin wrapper of 
>> “ERXExistsQualifier.” If you prefer, you could create that exists qualifier 
>> directly and specify if you want an “in” or exists syntax to be generated. 
>> 
>> AARON ROSENZWEIG / Chat 'n Bike
>> e:  [email protected]  t:  (301) 956-2319
>>      
>> 
>> On May 10, 2016, at 6:22 PM, Paul Hoadley <[email protected]> wrote:
>> 
>>> Hello,
>>> 
>>> I have two entities, User and Notice, each of which has a to-many 
>>> relationship to Role called roles. The business rule here works as follows. 
>>> Say Notice.roles contains two Roles, R1 and R2. If User.roles contains 
>>> either R1 or R2, then the Notice is applicable to that User—that is, 
>>> Notice.roles says that for each Role, the Notice applies to any User that 
>>> has that Role.
>>> 
>>> I have a static method on Notice to return an NSArray<Notice> applicable to 
>>> some supplied User. (There are other matching criteria, but this is the 
>>> part I want to try and simplify.) At the moment, I’m doing this:
>>> 
>>>     NSMutableArray<EOQualifier> roleQuals = new 
>>> NSMutableArray<EOQualifier>();
>>>     for (Role r : user.roles()) {
>>>             roleQuals.add(Notice.ROLES.containsObject(r));
>>>     }
>>>     EOQualifier roleQual = ERXQ.or(roleQuals);
>>> 
>>> While this works, it seems awkward. Is there a way to create this qualifier 
>>> (which is essentially looking for any match between User.roles and 
>>> Notice.roles) in one step?
>>> 
>>> 
>>> -- 
>>> Paul Hoadley
>>> http://logicsquad.net/
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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/aaron%40chatnbike.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/samuel%40samkar.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