the problem here is that what looks like a Block in fact isn't really. You cannot send messages to each of the resulting objects. The "Block" is used to generate an SQL statement, and there is no way to determine what isEffectiveOn: would look like in SQL by simply analyzing the descriptor.
I wish I could call some nice Smalltalk methods on rows as well, but GLORP does not support this, afaik. And I guess it is not really easy to implement. You'd have to decide for each message send in a Block whether it is something that can be expressed in SQL or has to be executed on a materialized object.It would be great to simply forget about the SQL nature and write normal select:/reject: expressions and have Glorp determine how to convert parts of them into SQL and parts as Smalltalkcode.
So I am not aware of any other possibility than turning such things into a two-pass select. First a readManyOf:where: for everything that's directly mapped, and a subsequent "pure old Smalltalk" select: on the results for everything else.
I am afraid this is a very expensive feature, however.
Am Dienstag, 23. Juli 2013 17:44:48 UTC+2 schrieb Mariano Martinez Peck:Hi. I know I can have 2 scenarios when writing queries:1) Compare instance variables that have been mapped to fields. Example:session readManyOf: XXX where: [ :object | object xxx = 'ABX' ].
2) Compare using DOMAIN MODEL METHODS that are NOT mapped to anything:session readManyOf: XXX where: [ :object | (object isEffectiveOn: Date today) ]In the first case 1) the #xxx method is an accessor for an instVar that is mapped to a field. Hence, Glorp can write the SQL in a way to filter the rows in the DB and just bring to memory the one that satisfies.Case 2) would need to instantiate each row of the table, send the message #isEffectiveOn: and check if it's true or not. So, I have 2 questions here:a) How can I make such a query work? The same query of the scenario 2 does not work for me and I get a MessageNotUnderstood: BaseExpression>>convertedDbValueOf: (I can attach PharoDebug.log if it helps).b) do such type of queries (scenario 2) bring only one object at a time and only keep the ones that satisfy the conditions or it brings (instantiates) all rows/objects at the same time in memory and then filter them? I think this is important because there are some of my tables that won't fit in memory.c) if the answer to b) is that you do one by one (which I don't think so), all (or at least several) plain rows will be in memory right? I don't think you will go to the db for each row..Thanks in advance,--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group...@googlegroups.com.
To post to this group, send email to glorp...@googlegroups.com.
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/groups/opt_out.