Expand with Condition
Sat, 11/06/2010 - 22:53
I'm using Expand in my QueryArray, to achieve early binding between two tables in a many to one relationship, similar to the QQ::Clause(QQ::Expand(QQN::Project()->ManagerPerson)) example, but in a QueryArray. It works fine and produces excellent performance. However, I need to apply a Condition to a column in the ManagerPerson segment. Is there a way to do this? I've been successful in adding the Condition and it produces no errors, but it is being ignored.
You have two options.
If you want to limit the Project list, just add it as a normal condition.
If you just want to leave the ManagerPerson as null in some cases, you can pass a condition as the second parameter to the Expand.
Vexed, thanks for the reply. I want to apply a condition to ManagerPerson, but the condition is being ignored.
Can you give an example in code? I use conditional expands in our live site without issue.
Also, Laceja, I encourage you to look at the SQL statement that results from that QQuery - is it what you expect?
Thanks guys. I ended up coding my own custom SQL to solve the problem. However, I have since discovered the root of the problem. I didn't restate the condition (Equal in this case) for the second condition in the AndCondition. It seems, however, some sort of error message should be generated, rather than simply ignoring the condition.
I'd love to add validation logic for that. Can you share the QQuery statement that should have thrown an exception but didn't?
Hi Alex,
Yes, for example, the following examples works just as one would expect:
$objTempTable = Steelhardnesstemps::QueryArray(QQ::AndCondition(
QQ::Equal(QQN::Steelhardnesstemps()->MaterialType,$this->txtMaterialType->Text),
QQ::Equal(QQN::Steelhardnesstemps()->OpCode,$this->pnlOpsMaster->txtOpCode[$op]->Text),
QQ::Equal(QQN::Steelhardnesstemps()->Scale,$this->pnlRqmtsMaster->txtRqmtScale[$rqmt]->Text)),
QQ::Clause(QQ::OrderBy(QQN::Steelhardnesstemps()->LowRc,false))
However, the following example does not work and produces no errors:
$objTempTable = Steelhardnesstemps::QueryArray(QQ::AndCondition(
QQ::Equal(QQN::Steelhardnesstemps()->MaterialType,$this->txtMaterialType->Text,
QQN::Steelhardnesstemps()->OpCode,$this->pnlOpsMaster->txtOpCode[$op]->Text,
QQN::Steelhardnesstemps()->Scale,$this->pnlRqmtsMaster->txtRqmtScale[$rqmt]->Text)),
QQ::Clause(QQ::OrderBy(QQN::Steelhardnesstemps()->LowRc,false))
);
LaCeja,
May I ask for your help with getting this set of tests / validations into the core? You're intimately familiar with the problem space, and you'd likely be the best person to write the tests and the validation logic for it.
Would you be up for writing the unit tests (against the sample database) to repro the problem, and then adding validation tests to the QQuery part of the framework? This would really help everyone!
If you're up for it, make a ticket and give it a shot! We'll be here to help!
-Alex
So basically you passed in extra parameters to a function that only accepts 2. I'm not sure this is the kind of thing we want to check for, since to do it right, it would be overhead on every single function in the entire framework.
Vexed, you would know far better than I, of how much overhead it would add. For me, it's no longer an issue, because I spent the time testing to discover the cause of my problem. However, I can imagine there are/have been others, who have gone through the same exercise. Maybe it would be a better investment in efforts to simply add a line or two of warning to the examples. I know I regularly refer to them, while developing. That said, please let me know, if you still want a ticket opened, and I'll do so.
Also, I'll be opening another comment to make some suggestions for ORM enhancements.
Basically to check for this we'd have to add a func_num_args() check to EVERY function in the framework. I don't see this as being worthwhile. And I also would have expected PHP itself to have caught this. Do you have STRICT error reporting turned on?
Vexed, as I said, I now understand the requirements, so this isn't a problem for me, personally. However, it does seem to me, given there are no error messages, the requirement should be pointed out in the example. Yes, I do have STRICT error reporting turned on. Syntactically, the code is correct, but simply fails in the framework.
The bottom line is, for me, this is no longer a problem. So, to make such a change to the framework, just for me, is not required. As far as I'm concerned... no worries, case closed.
Folks - I haven't yet looked at the relevant code section, but based on just the discussion above, one question arises in my head - why is the relevant framework component using the "dynamic number of parameters" logic when the parameters are really fixed, and only two are allowed?
That's just it. It doesn't. It only accepts 2 parameters. Which is why I expected PHP_STRICT to cause a warning.