Sean,
thanks for your short overview of what SimplePersistence does. Sounds
useful for quite a few scenarios and might even carry you well through
production stages for some projects.
What I was talking about is also not meant to frustrate people. I've
only played with Mongo/Voyage for a few hours and I must say I was blown
away by the speed and ease of that stack. We got something running in a
few hours and it was impressive. So Mongo/Voyage is a cool thing to use.
I always wanted to use Magna on Pharo. I even started to implement my
own little clone of Magna in VA Smalltalk. I got into troubles when I
tried to nest transactions and get this concurrency stuff streamlined
somehow. We all know that besides naming and one-off problems, caching
and concurreny are the hardest problems in computing. I think there is
something about this. And so I gave up on that project... ;-)
In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a
very solid state somewhere between complete despair and freaking out
about how cool things are. I love and hate that stack from the bottom of
my heart.
The cool thing about an RDB is (and will sure be for quite a while)
three letters. S, Q and L. There are lots of highly sophisticated GUI
tools to query, manage, correct your data. And you can simply do
everything form a command prompt, in an ssh session from your smartphone
in a hotel toilet on the other side of the planet.
Sure, using pure Smalltalk objects and not worry about n:m
relationships, not having to write mappings and not having to end up
with an object model that is driven mostly by what your O/R mapper can
handle, sound great. And it is. Until you realize you also need to think
about query optimizations, reorganizations, indexes and whatnot in an
object database. There are also compromises to make.
But, hey, I said all of that before.
So maybe approaches like fuel, SimplePersistence (or BOSS or Object
Swapper) are the best thing to start with when you need to find out
about your architectural and business ideas first (am I building the
right thing, will this feel good to a user, etc.), but once you are
beyond that state, you better dive into your options and decide soon.
Maybe using image saving or SimplePersistence is even good for
production in your case. It was good enough for dabbleDB for quite a
while, iirc, so why shouldn't it work for others? And maybe that is even
the best you can do to postpone the decision for as long as possible at
minimum opportunity cost.
I didn't dig deep enough into Voyage/Mongo to judge how expensive or
risky the changes to the design are. How hard is it to restructure the
root trees - say you need something that is now beneath some root to be
a root of its own? How would you do such changes?
I know I can do a lot of things of that kind with SQL. It is a second
looking glass and set of tools to view and manipulate the data.
Sometimes things are easier to do in Smalltalk, sometimes it is way too
slow on top of an ORM and a SQL query can do the same thing in a few
milliseconds.
But maybe I am asking the wrong questions fo Tim's purposes. I think I
understand what you (Tim) are looking for is not a big, complex project
but more like an experiment? I don't want to invalidate any of the given
suggestions, I know or at least believe that they each do a good job.
All I really wanted to warn you is that you will not easily be able to
go from one option to another, because each will have a deep impact on
your object model and application architecture.
Joachim
Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users:
jtuchel wrote
Sigh. Forget about the idea that it will be easy to switch your
persistence later....I am not commenting on SimplePersistence here, I
don't even know what it
does or doesn't.
Joachim,
Thanks for this interesting perspective. I've never had the (mis?!)fortune
of a project growing enough to force me to make those tough choices! For
SimplePersistence I will say that I view it as a way to *delay* making *any*
choices until you are forced to. It's really just a layer of sugar on top of
Fuel (it used to use the old school Squeak equivalent serialization
mechanism - I forget the name and that might still work). You tell it what
classes to serialize. Implement two methods for each class that get and set
the data, and then it saves the whole thing as one object graph.
Tim,
If you use SimplePersistence, please keep me posted about your experience.
I'm happy to help.
NB I have maintained and extended the library, but it is the work of Ramon
Leon
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
