This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Gemstone vs. an RDBMS Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Petr Stepanek is talking about Gemstone, and comparing it to relational technology. So - starting with the object model. If you are using Smalltalk, then you have one - the example in this case is a call center (CRM) system. The problem is that the underlying data (object) model is not immediately known, and will be changing over time. This customer wants live development on a 24x7 system. They have looked at various commercial CRM systems, and have not been impressed - so they opted for a custom system.

Live Development, constant change to a running production system (you mean, that thing that critics like Isaac says customers don't want?) - that's what they want here. They did a fair amount of reading for possible solutions, including the ValueWithHistory idea put forth by Kent Beck - where you use Decorators on objects instead of instance variables. They ended up with what they call a Linked Object Model (if I can get a copy of the presentation, I'll post a link - there are some pictures on the slides). In general, they have a "cloud of data" with various links between the objects. They use a Node class which holds links between objects. They ended up with the following rough choices (the picture of the object model is complex :)

• an RDB with two huge tables (Links and Nodes)
• plus additional tables for Node subclasses
• Or an OODB (they selected Gemstone)

So how do you get at the data to change it - write accessing methods!

Setter

Link new
	node1: aPerson;
	node2: aName;
	meaning12: 'name';
	meaning 21: 'person';
	hook

Getter

^OneLinkTraverser new
	node1: self;
	meaning12: 'name';
	validAt: Timestamp now;
	node2.

Slower than direct accessors, but they have been able to deal with that. They keep links in Gemstone, and they implemented the OneLinkTraverser class (etc) in Gemstone (so that it runs on the server). They have also implemented aggressive caching. The pros and cons:

Cons

• Complex - not immediately obvious or "natural"
• Confusing - inspecting is complex (solvable with Trippy in VW via #inspectorExtraAttributes) - not solvable in Gemstone

Pros

• Less work - no idea how they could do this (well) in an RDBMS
• Past data handled same as current data
• May change model with no GS class migration on a live system
• High chance of committing transaction in GS
• Can still use GS indexes.

On the business side, this is great for complex models that change over time - which this one does. Past data is important, and easily accessible. Fast responses for requests from any direction are supported in this model, and that's critical in this business.