MinneStore^TM version 2.0

Why the name MinneStore?

I grew up in Minnesota and have recently returned after 11 years in the Chicago area. Since many places in Minnesota start with "Minne" and since I am pretty proud of where I grew up, I incorporated its name into the name of my product.

How do you pronounce MinneStore?

Pronounce it like "minna-store". But if that seems too hard to say, "mini-store" is also acceptable.

Why was MinneStore written?

When I started learning Smalltalk, there was no easy way of storing many objects without spending hundreds of dollars. When I got a job using Smalltalk, I found that an inexpensive (free) but reliable storage and retrieval, and indexing mechanism was really needed for prototyping purposes. These two things got me interested in writing Minnestore.

What is the GNU General Public License?

The following quote comes from the preamble to the GNU General Public License.

"The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users."

What was version 1?

Version 1 worked well, but it took a long time to write and was overly complex because it wasn't very "object-oriented". When I wanted to add features to version 1, it got tougher and tougher. So I rewrote the data access portion to be much more "object-oriented" and thus much more flexible. In version 2, I have also added a framework for storing a complex object in multiple ObjectSets.

What are some strengths of MinneStore v2?

1. It is easy to store and retrieve objects using an english-like syntax.
2. Indexing of objects is flexible and efficient.
3. MinneStore will index sentences or phrases and allow you to search for key words.
4. Transaction commit/rollback -- If a complex object store fails, the data and indexes will be rolled back.
5. Multiple users can access the same object files on a LAN without unkowingly losing changes.
6. An object can store its "aspects" in separate "object sets".

What are some weaknesses of MinneStore v2?

1. It uses more disk space than a relational database would use.
2. I haven't added any database management tools yet. (Like an index reorganizer, etc).
3. If power is interrupted during a transaction commit, not all data will be rolled back.

How is object identity maintained?

If an object is read more than once, the subsequent reads will return the exact same object as the first read. This is to protect object identity. In the future I may supply a way to clear the instance cache and force a new database read.

When an object is stored for the first time, it is assigned a database id number. When an object is retrieved, changed, and stored again, the old object will be replaced on disk using that id number. Currently, if a copy is made of a stored object, the copy will be stored separately from the original object.

How are objects locked for multi-user concurrency?

MinneStore uses an optimistic locking scheme. Each time an object is stored, its version number is updated. When updating an object on disk, the version number is checked. If the version number has changed since the object was read, then an error is signaled and the application must ask the user to redo their changes to the new object. The benefit with optimistic locking is that no one will be locked out of an object because someone locked it and then went away from their desk for a long time. Basically, this scheme encourages the user to save their object changes quickly.

How do I use it?

Included are Smalltalk "file-outs" to file into your image. A demo example of how to use it are in subclasses of MinneStoreExamples. Click here to see additional code examples now.

How do I get this code?

Send me an e-mail at joncrlsn@eta.k12.mn.us
or download a beta version now by clicking here.
Either way, please let me know if this software has benefitted you (or if you find bugs).

Things to be aware of when using MinneStore

• Everything an object points to (except aspects) will be stored with it.
• If an object is retrieved and copied, the copy will not overwrite the old object when stored because copying loses the original database id number.
• Objects with references to blocks cannot be stored. This is a limitation of the Digitalk ObjectFiler.
• Index values cannot come from an "aspect" object.