Frequently Asked Questions

Please send your questions so I can add them.

• What are some strengths of MinneStore?
• What are some weaknesses of MinneStore?
• Can a database created using one Smalltalk be read by another version of Smalltalk?
• How is object identity maintained?
• How are objects locked for multi-user concurrency?
• How do I use it?
• Why the name MinneStore?
• Why was MinneStore written?
• What was version 1?
• What are some things to be aware of when using MinneStore?

1. Storing a network of inter-related objects.
2. The English-like syntax makes it easy to store and retrieve objects
3. Each objectSet can have multiple indexes
4. Sentences or phrases can be indexed by each word
5. Transaction commit/rollback
6. Garbage collection is not necessary. As objects are changed and deleted, disk space space is automatically reclaimed.
7. Multiple users will be able to access the same database on a LAN without unkowingly losing changes.

What are some weaknesses of MinneStore?

1. Currently, If power is interrupted during a transaction commit, not all data will be rolled back. Since the commit happens so quickly, this is very unlikely.
2. It uses more disk space than a relational database would use.
3. There are not any special database management tools yet. (Like an index reorganizer, etc).
4. A more efficient backup mechanism is needed. The current backup procedure is to copy the whole directory (including indexes).
5. I mention this because this is seen as a weakness by some, but it enhances portability. MinneStore stores its objects in multiple files which increase in number as the database grows.
6. MinneStore currently runs on the client but can stores its objects on the LAN. This makes it easier to implement, but makes it more difficult to maintain. Since this database is only intended for a single-user or, at most, a small department application, this shouldn't be a problem.
7. MinneStore was not written for a multi-threaded environment. If used as a server-based database all operations must block until they are complete.

Can a database created using one Smalltalk be read by another version of Smalltalk?

No. For example, a database created by the Dolphin version of MinneStore cannot be read by the VisualAge version of MinneStore. This is because the object serialization format used by each Smalltalk is not compatible. I have thought of storing the objects in a neutral text-based XML format but am not ready to tackle the issues that go with that yet.

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.

When an object is stored for the first time, it is assigned a database id number (using the properties feature supplied with Visual Smalltalk and Dolphin). When an object is retrieved, changed, and stored again, the old object will be replaced on disk using that id number. If a copy is made of a previously stored object, the copy will be stored separately from the original object.

How are objects locked for multi-user concurrency?

Warning, the multiple-user feature will not be available until version 2.1 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 people will not be locked out of an object because someone locked it and then went away from their desk for a long time. In short, 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.

Why the name MinneStore?

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

Why was MinneStore written?

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

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" (yes, use of Smalltalk does not guarantee good code). When I wanted to add features to version 1, it got tougher and tougher. So I threw out the data access portion and rewrote it to be much more "object-oriented" and thus much more flexible.

What are some 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 if you use the MinneStoreDB>>store: method because copying loses the original database id number. Use the MinneStoreDB>>replace:with: method to do this.
• Some Smalltalk "object filers" will not allow storing of objects with references to blocks.
• Index values cannot come from an "aspect" object.