The opposite Glorp Gemstone experience

Hi,

I basically still seem to misunderstand the following:

I have a situation where I have a glorp only application with numerous list datasets and treeviews.

One of my major challenges is related to maintaining a fast UI when the model grows bigger and bigger, and I used  to get quite some speed out of simpler modelisations with more complexe text queries and with multiple descriptors using the same table.

Now in order to avoid TreeModel's to read all proxies of a TreeModel (objects with parent child relationships defined by a link table), I subclassed one of my major objects (in my case the tasks of a project management tool) directly from AssociationTreeWithParent.

This works pritty well on a number of occasions and notably when toggling leaf open and close, where it will now query the children once and only if requested.

Things go wrong however when I want to use the aspects (MultiSelectionInList, MultiSelectionInTree) of dataset or treeviews directly.

In this example I just need the date of the first Widget entry.

myFirstDay := taskColum list first value task_start_date.

taskColum is either a MultiSelectionInList or a MultiSelectionInTree.

Due to the "Opposite Gemstone experience" this will provoke glorp to querry but not only the first task on the list. It will query the complete data model and read all links and associated tasks.

For a model with 1600 tasks this will last a whopping 6 seconds.

Instead of reading the date from an instance variable I therefor have to re-query from the database with something like.

query := Glorp.Query readOneOf: Task where: [:each | each key = taskColum list first value key].

query retrieve: #task_start_date.

myFirstDay := self getGlorpSession execute: query.

This will last a way more acceptable 12 miliseconds.

The amazing thing here is that I used the same object differently instead of requesting the value part I requested the key part to make the query, and here it gives access to the values without providing the "Opposite Gemstone experience".

Thanks for helping to undertand this better.

@+Maarten,

Well Glorp normally provides what the Userguide (Page 17) calls the Gemstone illusion, as it hides you away from SQL, and it allows acces from objects to objects taking care of quearing were needed.

In this specific case all this confort actually works against me.

There must be some trick however to bypass this.

@+Maarten,

-----Original Message-----
From: "Joerg Beekmann, DeepCove Labs" <[hidden email]>
Sent: Friday, 18 May, 2012 18:02
To: [hidden email], "VWNC" <[hidden email]>, [hidden email]
Subject: RE: [vwnc] The opposite Glorp Gemstone experience