[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