[ANN] MagmaServerLoader-cmm.25

[Hilaire Fernandes]

Chris Muller a écrit :
> I am pleased to announce the latest Magma upgrade!  The main thrust of this release are bug fixes but, primarily, one particular bug which required a significant amount of work; complete transparency of "pseudo-persistent" MagmaCollectionReaders.  By pseudo-persistent I mean Readers that are the result-sets of a query on a new, automatically created MagmaCollection borned from using one of the "luxury" query features (either distinctness or sorting by other than the most-optimal attribute) on another MagmaCollection.  Although these new Reader/Collection pairs, are not (initially, at least) truly persistent because they are not referenced by the persistent object model, they do, like persistent collections, require support by back-end (hash-index) files and managed by a server object.
> 
> Until now, attempting to further query these "result set" Readers or attach them to the persistent graph did not work.  Now it does.  Further, thanks to Hilaire's great suggestion, further querying of Readers is fully symmetrical with MagmaCollections, i.e., you can use  #where: and friends on a Reader.

Not sure about how to use it. I have some index (my famous DateAndTime 
one) which is deep in a tree of persisted nested MagmaCollection.
Kind of:
  IFILearners
   +--IFICompetencyLearningStates
      +--IFIEtayageAchievements
         +--IFIEtayageStepAchievement
            +--IFIExerciceRecord

And my DateAndTime index is down in the IFIExerciceRecord index.
I am not sure if it is possible to do a query on this index in a cost 
effective way. It looks like a solution is to enumerate the whole 
collections, but at least being able to do it in the server side will 
more cost effective, otherwise it will be overkill.
Or may be a design problem of me... Inversing the nested collection will 
just report the problem. Or may be nesting collection is just bad 
behavior, but so handy.. Hum, thinking loudly.

Hilaire