Tim,
Am 06.10.20 um 14:47 schrieb Tim Mackinnon:
Some great answers everyone - really appreciate it.
I think that all things considered, SimplePersistence seems like a
very easy place to start, and then I can "upgrade" when my super
awesome idea (not), exceeds its bounds.
Sigh. Forget about the idea that it will be easy to switch your
persistence later. There are lots of little (and not so little) things
to consider for each approach, be it an ORM, an object database or just
a bunch of serialized objects. It starts with the bookkeeping for
references between objects. Is it enough to remove an object from a
Collection or will it somehow survive in your db and come back as a
surprise after you started a new transction? Will a deleted object be
deleted or just unreachable? Do I have to care about all possible paths
to this object if I really want it to be deleted? Will my ORB possible
re-insert it in the next transaction because I don't understand how an
ORM works?
Don't fool yourself into thinking there is something like a transparent
persistence layer. If anybody ever says so, walk away, say thank you and
forget about that person as fast as you can.
I am not commenting on SimplePersistence here, I don't even know what it
does or doesn't. I am talking about experiences made with both OODBs and
ORMs like Glorp.
I've been through tough times with an architecture that I thought to be
a good idea: keep persistence in a separate layer that just spits out
objects and swallows new or changed ones. Works well in a prototype. But
on top of Glorp and with a few more than a hand full of objects, you end
up wanting to write real database queries. So you need to get a hold of
something that represents the database, say a Session object. You end up
either trying to wrapper the query building in your clever layer and end
up with friggin slow performance or give up on your nice layering to
make your application at least bearable. Sometimes you even give up
navigating between objects and replace a simple getter with a DB query
to get good performance (ever waited for 600 proxies in a collection to
each deserialize itself when accessing the #items of your Stock object?
- you better write a sql query fetching them all at once...)
You need query by example? Good luck in an Object DB. You either use DB
specific queries and hand-tuned indices, or you navigate your object net
and have the user wait a little. Or you design your object model around
the search paths (which is hard once your model has evolved a while).
In Mongo/Voyage, you need to make a decision of what objects will always
be tied closely together (referenced by a root) and can be retrieved on
their own. You think in object trees rather than objects. We've thrown
CouchDB out of our project. Not because it is a bad NoSQL database, but
because we couldn't make it work well in our overall architecture in
which the primary store is a relational Database.
So please be aware that once your app gets a little more than just a
prototype, you need to make a decision: relational, dictinaries, tree-like
I guess this is not really helpful advice. I can't really tell you what
is right. I am cursing at Glorp every few days, but I also love it for
many great things it does for us. And I've had a few very "interesting"
lessons along the way, and am still in the process of learning about its
limits.
Joachim
I wonder if these answers should go somewhere in a tips section
somewhere, and get updated yearly.
@jonathan I had forgotten about those server tools - I think the last
time I did something it predated some earlier tips the Sven had given,
so will check it out. Back then, I did have a GitLab build pipeline
autodeploying for me, so I'm hoping I can re-incarnate all of that so
I can get my little app running with no fuss... lets see.
While I have a love/hate with Docker - I did wonder if there was
something for Pharo that just let me build my image into a container
and then it would just work with little system knowledge needed (as I
keep forgetting all the voodoo between times when I need it). Maybe
there is, or maybe it might come one day soon...
Tim
On Tue, 6 Oct 2020, at 9:40 AM, Jonathan van Alteren wrote:
Hi Tim,
I've been running Seaside applications on Hetzner cloud servers for
more than a year now, with great pleasure and success:
https://www.hetzner.com/cloud
I guess their servers are similar to Digital Ocean, although I
haven't followed the development of their products and solutions for
quite a while. Setting up a new server at Hetzner is a breeze, and
you can start already for as low as €2,49 per month!
We're using Voyage on MongoDB for persistence. After learning some
hard lessons (and I'm sure there are more to come ;-)), I really
enjoy the unobtrusiveness of it. Most of the time, it doesn't require
much attention and allows me to add persistence to real OO designs
quickly and easily. I find it a welcome change from the relational
database work I used to (need to) do, back when I was still doing
Java. The 'everything an object' principle of Pharo/Smalltalk really
makes it shine.
I can't help you with a list of tradeoffs though. If you come across
a set of arguments, I'd be happy to give feedback.
By the way, I forked Sven's pharo-server-tools project (here:
https://github.com/objectguild/pharo-server-tools) and have a routine
going that suits me well enough. Still lots of room for improvement,
but it's OK for my current needs.
Future plans are to use the Hetzner API to provision a new server and
use something like Chef or Ansible to install/configure it
automatically to be ready to deploy a Seaside application. I'd like
to integrate this into a full service CI/CD pipeline in the future,
to be able to do automated production deployments without service
interruption if possible. For this scenario, I would really also like
to switch to using GemStone for persistence.
Hope this helps! Let me know what you decide and I might be able to
help with some technical stuff.
Kind regards,
Jonathan van Alteren
Founding Member | Object Guild B.V.
/Sustainable Software for Purpose-Driven Organizations/
jvalte...@objectguild.com
On 6 Oct 2020, 00:23 +0200, Tim Mackinnon <tim@testit.works>, wrote:
Hi everyone - I’m wondering what is the recommended way to save some
simple user data for a Pharo application I would like to run on the
cloud (probably initially digital ocean, but could be AWS if it came
to it).
Initially I thought I might try and run my little app in Digital
ocean (I followed someone’s steps a few years ago, and had a simple
seaside app running quite well) - so I was thinking of starting there.
I know there is Sven’s P3 - but I’m not sure I’m ready to run and
maintain a SQL database for a simple application, but could be
persuaded it its simple to setup with little maintenance. Would
mongo be a suggestion - is that easy to setup and run? (And is that
Voyage?).
Possibly I could even use image persistence, and fuel out a
Dictionary from time to time - but I think that might be a little
bit too belt and braces for me.
Is there something that gives a little table of tradeoffs with some
simple ways to get started?
Tim
--
-----------------------------------------------------------------------
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
