SBlog - Data Store
Last updated at 1:44 am UTC on 17 January 2006
Jim Benson
Does the data store have to be transparently persistent? Not in my opinion. At the same time, it should be straightforward to put a different back end on the web log server. To me, it's not necessary to build a bridge across the chasm, but it'd be nice to leave a bridge building kit on the close side of the precipice with some guide wires already in place.
Avi Bryant
Well, it's difficult to both be non-transparent and to have it be
straightforward to swap out back ends - because each non-transparent
backend will be non-transparent in a different way. And, realistically, no persistence mechanism is truly transparent - they're all "leaky abstractions".
I can see being able to swap out different relational databases, or
possibly different object databases, but swapping between a relational database and an object database gets tricky the second you need to do any querying or indexing.
It depends at what level you expect to be able to swap stuff out,
though - I guess I can imagine having a set of abstract classes for the model, and concrete implementations of these using different persistence strategies.
Jim Benson
Sorry, I should have spoken more clearly. I agree with your assessment. I also think what I'm looking for is that 'entry point', a place where to hitch the ponies for heavy lifting. So you'd have an abstract class for defining the data store access points. The challenge would be to implement a Squeak based 'simple' data store, and define the abstract class. Then you derive from the abstract class if you want to add a different type of data back end. I afraid I made it sound like a literal swap out of parts, where I meant to say "with the proper fabrication".
Avi Bryant
No, it's just that I disagree on what the entry point should be. That is, I think you're picturing something like this:
Views —> Model —> AbstractStorage
|
|- Postgres Storage
|
|- OmniBase Storage
|
|- .....
I'm picturing something like this:
Views —-> Abstract Model
|
|- Postgres Model
|
|- OmniBase Model
|
|- ......
That is, I don't think we can easily come up with a single interface
between the model and the storage layer that will work for a wide enough range of storage possibilities.
Blaine Buxton
I was having thoughts on this issue. I think 1 week is an incredible deadline and I'm thinking most everyone is doing this in their spare time. Anyway, why not just use Minnestore? I did some reading up on it and it seems to be enough for what we need. I haven't used it, but I loaded it up in a Squeak image and all of the tests ran (so, I assume it works). This seems to be the most pragmatic approach and that way we can concentrate more on the domain. I'm thinking in 1 week, I'd rather worry about getting the domain right. We can always change the persistence mechanism if we design it right or Minnestore isn't up to snuff. I would rather reuse something than build something from scratch. There's also several excellent persistence frameworks (GLORP being one) on SqueakMap. I think we should at least pick one of those.
Jim Benson
My viewpoint: Make it as simple as possible to start, you could just as easily use a SmartFileRef, flat files or something simple to get started (and for newbies to grok), which is probably adequate for maintaining a personal weblog or three. One thing I require is that there is an obvious "hook" to places where you can bring in heavy, non-mainstream Squeak or outside machinery for the case where you want to start building an industrial strength application.
SBlog Challenge Participants Area
sblog top
