Niall Ross wrote:
Dear Herby, adding #includesKey: is certainly doable. If you look at callers above and subcallers below #anySatisfyDefault: you will see the issues involved. Your includesKey: needs the same degree of platform-awareness that Glorp's #anySatisfy: and #allSatisfy: implementations use. But since #anySatisfy: is there, you have a ready template to follow.
I don't feel competent enough, from what I looked, Glorp innards are a bit complex.
Alternatively, I may well add #includesKey: - though not as my most urgent task. :-) I did a fair amount of work to extend the usability of DictionaryMappings in Glorp three years ago (part of demonstrating the ObjectStudio business-mapping/Glorp-generating tools - see my ESUG 2014 presentation for details) but I did not then think of providing #includesKey:. Thanks for suggesting the idea.
My pleasure. :-) As I wrote elsewhere, also #keys is something (probably the most general) one that could be added as a matter of allowing to work with the key field - as far as I was able to find out, there is no way to actually get to the key, for which I found workaround since I mapped object, but would be out of luck if I mapped single primitive value. For the moment, it is not pressing, but yes, it would be nice to be able to have #keys mapping to key field and #includesKey: as an idiomatic way to do keys includes:. Thanks again, Herby
If you were to work on this, be aware:
- always reinitialise FunctionExpression class after adding/changing any Glorp function (or just close and reopen your image, of course)
- If (and only if) you construct Query whereClauses in stages (e.g. you have code like
myQuery AND: [:customer | customer orders includesKey: #onlineOrders]
or similar) then, using its callers in GlorpTest as a guide, know when you might need to send #setUpBaseFromSession: to your query while doing so. (N.B. that method is a Glorp version 8.2.1 addition; you will not have it in older Glorp.) The point is that stage-constructed where clauses must convert from block to expression before execution, to combine the stages. Any that use #anySatisfy:/#allSatisfy: need platform-specific information to do this; I would expect any #includesKey: implementation to be the same.
HTH Niall Ross
Tom Robinson wrote:
Hi Herby,
In my opinion, the way you found to make it work is the way it should be. The reason is that the first way doesn't translate into SQL and the second one does. It might be possible to add includesKey: functionality but resolving that to SQL would be more complex. I would not call this a bug. I would call it a limitation of the implementation. I don't know of anyone planning to add this feature to Glorp right now.
Regards,
Tom
On 10/24/2017 12:27 PM, Herby VojÄÃk wrote:
Hello!
I am using a DictionaryMapping in my code, and I wanted to use #includesKey: in #where: clause (something akin
each tools includesKey: aToolId
) to select only rows for which DictionaryMapping uses certain key. It failed with the error in the lines of "#tools does not resolve to field". I had to come up with
each tools anySatisfy: [ :tool | tool id = aToolId ]
Is it the bug / feature / problem in my approach? If bug, is it planned to add #includesKey: translation to DictionaryMapping?
Thanks, Herby