Hiya!
Ok, I stumbled on this code:
minimumSearchSpaceSizeUsing: aMaLargeCollectionManager | calculateSizeBlock | calculateSizeBlock _ [ : each | each minimumSearchSpaceSizeUsing: aMaLargeCollectionManager ]. ^ self isConjunction ifTrue: [ self terms detectMin: calculateSizeBlock ] ifFalse: [ self terms detectSum: calculateSizeBlock ]
...which wrongly assumes that detectMin: returns the size instead of the term itself. I changed "self terms detectMin: calculateSizeBlock" to "(self terms collect: calculateSizeBlock) min".
...which creates an intermediate collection, but whatever. :) Not sure how come this have gone unnoticed, perhaps there is no test exercising this as a conjunction. And yes, detectSum: and is dubiously named - it is no "detect" IMHO - it should be called sum:.
On to my question - is it planned that where: queries could also operate on attributes that are not indexed? Even if it is planned I can probably not wait for that - I will have to split my code into a where: followed by a "normal" select: I guess.
Or actually add select:upTo: to the reader that will return up to x number of objects.
regards, Göran
Ok, I stumbled on this code: ... ....which wrongly assumes that detectMin: returns the size instead of
Indeed. Another great catch Göran, thanks.
I am putting together a new release which will include this and your other fixes.
the term itself. I changed "self terms detectMin: calculateSizeBlock" to "(self terms collect: calculateSizeBlock) min".
....which creates an intermediate collection, but whatever. :)
This will not affect performance at all, thanks for the consideration.
Not sure how come this have gone unnoticed, perhaps there is no test exercising this as a conjunction.
Yes, conjunctions are part of the tests. Due to the query normalisation that occurs in the client, to hit this code requires a disjunction as a parent of a conjunction, as in:
condition1 | (condition2 & condition3)
and this is not part of the tests. Most of the testing effort focuses on the combinations of distinctness, sorting (ascending and descending), and integration of local changes.
And yes, detectSum: and is dubiously named - it is no "detect" IMHO - it should be called sum:.
I agree.
On to my question - is it planned that where: queries could also operate on attributes that are not indexed?
It's not planned at this time. As much as I would like to have that, I know no way to do it, given the robust api. The select: requires a block executed on the client (because domain classes are not present on the server), so even simple #size and #at: is impossible.
Hi!
Chris Muller chris@funkyobjects.org wrote:
On to my question - is it planned that where: queries could also operate on attributes that are not indexed?
It's not planned at this time. As much as I would like to have that, I know no way to do it, given the robust api. The select: requires a block executed on the client (because domain classes are not present on the server), so even simple #size and #at: is impossible.
Ok, then I know!
I ask mainly because then I will go ahead and split my Gjallar filtering into two steps - first use Magma #where: and then follow that up with a regular select: (or actually - on demand testing probably - as the user views the "next 10" hits, if Magma returns more than say 100 hits).
regards, Göran
magma@lists.squeakfoundation.org