John-Reed Maffeo wrote:

stp,

Thank you.

You're quite welcome!

I hope I get a chance to try this out this weekend. I have some data that I would like to objectify and store outside the image.

That's what it's there for!

If you have any suggestions for an approach to this please let me know.

Take a look at the examples on the MinneStore web site (http://www.objectcomposition.com). I also put the basic syntax examples in the file ftp://ftp.create.ucsb.edu/pub/stp/OODB/MStore-2.4b/SyntaxExamples.t. The basic usage pattern is to create a database given a storage directory, to create one or more object sets in it (these correspond to classes), and to define indeces for the object sets (corresponding to instance variables and accessors). One can then add object to an object set, or retrieve objects based on queries. The basic code for this looks like:

"Create a DB" db := MinneStoreDB newOn: dirName.

"Add an object set for class Parts" (db addObjectSetNamed: #Parts) storesClass: Part; indexOn: #name domain: String; indexOn: #number domain: Integer.

"Store a couple of parts objects" db store: (Part name: 'spout' number: 101). db store: (Part name: 'lever' number: 102).

"Save to disk" db save.

...later...

"Re-open DB" db := MinneStoreDB openOn: dirName.

"Select parts" results := (db getAll: #Parts) where: #number between: 100 and: 110; "inclusive" execute.

If you have any specific tasks that a newbie could perform to help with the MinneStore project let me know and I will try to do it.

YES, LOTS! Well, aside from basic bug chasing (they're still there, I know) and portability (it's only guaranteed to work on Macs at the moment, and it requires the new 2.4 directory primitives), I'm working on three main topics: performance, performance, and flexibility. The performance issues are related to the speed and compactness of Squeak ReferenceStreams (I'd like to see special compact/fast formats for lots more classes -- this means writing storeDataOn and readDataFrom methods) and to the caching within MinneStore (I think it does too much I/O, but am still learning about it). The flexibility issues are related to the use of arbitrary blocks for generating indeces (rather than requiring a selector for which an accessing method exists) and on support for dynamic indeces and indexing-on-demand.

Collaborators are invited!