I have just posted a new version of Magma to SqueakMap, as well as the "MagmaTester" project of squeaksource.
It was pretty lame of me to discourage anyone from using a part of Magma that is there to be used. I am therefore pleased, at last, to put to rest this issue with Magma "luxury" queries once and for all.
Prior to release 44, beta2, use of the luxury features of a MagmaCollectionReader:
- use of a disjunction (|) - requiring distinct results - requiring sort by an attribute other than the optimized attribute
would mean the entire query would be executed on the server, even if the application only needed the initial results of the query. This is wasteful, and could cause the server to get bogged down for an application that tried to use frequent, ad-hoc luxury queries against large collections.
Now, however, the MagmaCollectionReader>>#release method causes the server resources associated with the luxury query to be cleaned up. This will allow applications to now use these luxury query features for ad-hoc querying.
It has *always been* the Magma application-developer's responsibility to send #release to a MagmaCollectionReader when finished with it so, theoretically, there should be no need for any application changes. Before 44Beta2, calling #release had a minimal benefit, merely releasing an in-memory Listener dependent. Now, #release also cleans up significant server resources in the case of a luxury query, a great benefit. If you need scalability, don't let this slide!
My hope is that those folks coming to Magma from a relational-db background will appreciate this feature. I do recall, when using Java / Oracle some years ago, that I had to release my ResultSet object when done with it. Therefore, the lack-of-transparency regarding this particular operation will, hopefully, be understood.
Despite the improvement, I still encourage developers to look for more OO solutions to app problems. Magma is an ODBMS and works well with large models that do not contain MagmaCollections. MagmaCollections were never intended as the primary domain mechanism of Magma applications. It was always intended as a secondary, supplemental structure (originally intended to solve the use-case of "finding objects by keyword").
It has been tested in Squeak 3.9 and Pharo, but if anyone has any questions or issues, please let me know.
- Chris
magma@lists.squeakfoundation.org