Re: More Readable EOQualifiers

Hi all,

I've been doing a lot of work with EOQualifiers in the past few months,

and while the new ERXKey-based, chainable qualifiers are a huge leap ahead of the standard EOQualifiers in terms of readability and clarity, they have always seemed just short of ideal. I believe I've come up with an improvement, but I want to get everyone's opinion first. Yes, even yours, Anjo. I'm ready. ;-) 

First, let me give you a basic use case.

I have two Entities: 

1) School

2) Student

Their relationship to each other is: School <->> Student  (Shhh! it's just an example. Let's not complicate things.)

Now, let's say for a given school, I want all the active, red-headed students. Here's the way I originally learned (shudder):

EOQualifier qual1 = EOQualifier.qualifierWithQualifierFormat("hairColor=%@", new NSArray("Red"));

EOQualifier qual2 = new EOKeyValueQualifier("isActive", EOQualifier.QualifierOperatorEqual, true);

NSArray studentQualifier = new NSMutableArray();

studentQualifier.add(qual1);

studentQualifier.add(qual2);

EOQualifier studentQualifiers = new EOAndQualifier(studentQualifier);

NSArray redheadedStudents = mySchool().students(studentQualifiers);

Horribly unreadable,

with lots of grunt-work to get things setup before you can even use the qualifier for anything! That and incredibly unsafe due to the use of "Magic Strings" that will break, but only at runtime when you change anything in the model (sure, there's ways around that, but they usually make the code even less readable).

Then along came ERXKey chainable qualifiers and you could do it all with one (reasonable) line of code:

NSArray<Student> redheadedStudents = mySchool.students(Student.IS_ACTIVE.isTrue().and(Student.HAIR_COLOR.eq("Red")));

Which is pretty darn readable. Hugely better than the original way. HUGELY. But yet... you still need to spend a bit of time interpreting it when you first come across it.

My new strategy combines still doing some setup, but the setup is explicitly for making things easier to read.

EOQualifier haveRedHair = Student.HAIR_COLOR.eq(MyAppConstants.RED_HAIR);

EOQualifier areActive = Student.IS_ACTIVE.isTrue();

NSArray redheadedStudents = mySchool().students(Student.that(haveRedHair).and(areActive));

"But where did the 'that(EOQualifier)' come from?" you ask?

That's (no pun intended) the key (oh, wow. I'm on a roll!) to the improvement. 

I have added the following simple method to my EOGenericRecord subclass:

public static ERXAndQualifier that(EOQualifier qualifier) {

    return new ERXAndQualifier(new NSArray<EOQualifier>(qualifier));

}

Basically, all this method does is coerce a standard EOQualifier into a chainable one (IERXChainableQualifier) and uses a conjunction to better tie the qualifier(s) to the Entity that they are qualifying. My #1 goal was to make places where I use qualifiers as sentence-like as possible, and I think Student.that(haveRedHair).and(areActive) is very readable.

So, what do you all think? Is there some flaw inherent in the system? Am I missing something? Would it be worth putting into ERXGenericRecord?

EOQualifier haveRedHair = Student.HAIR_COLOR.eq(MyAppConstants.RED_HAIR);

EOQualifier areActive = Student.IS_ACTIVE.isTrue();