[Seaside] Persistent object framework

C. David Shaffer cdshaffer at acm.org
Thu May 13 17:04:57 CEST 2004


Jason Dufair wrote:

>Avi Bryant <avi at beta4.com> writes:
>
>  
>
>>The thing that comes to mind, with an OODB, is indexing.  This is
>>something that RDBs do for you, but that you need to handle on your
>>own in an object setting.  The BTree class I put on SqueakMap is a
>>good building block, but I'd like to build out something a little more
>>sophisticated, that would manage several indices at once and could be
>>told to update them all at once for a given object.  I'm thinking of
>>an interface something like this:
>>
>>mgr := IndexManager new.
>>mgr indexSelector: #name of: Person.
>>mgr indexSelector: #startDate of: Project.
>>.....
>>
>>person := Person new name: 'Avi'.
>>mgr update: person.
>>project := Project startingToday.
>>mgr update: project.
>>
>>people := mgr findAll: Person where: #name is: 'John'.
>>
>>person name: 'Avram'.
>>mgr update: person.
>>...
>>
>>Make sense?
>>    
>>
>
>This does make sense.  But it seems a bit cumbersome.  Perhaps we could
>  
>
Rather than having to tell the index to "update" why not have a two 
phase commit in KKRecordCache>>commitObject:?  You could send 
"goodsAboutToCommit" to all dirty objects and then you could have a 
default impl to update all indices.  Then you'd have to make a second 
pass to ensure that all of the dirty objects are really being 
committed.  I have some OmniBase code which does this kind of thing.  I 
was fairly minimal but it did avoid updating indices when the "key" 
didn't change.  If you don't see any problems with this then I'll bring 
it over to Squeak and rework it for GOODS.

-- 
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com




More information about the Seaside mailing list