pharo-users@lists.pharo.org

Any question about pharo is welcome

View all threads

Easiest light weight cloud/web persistence for Pharo?

TM
Tim Mackinnon
Mon, Oct 5, 2020 10:23 PM

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

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
GC
Gabriel Cotelli
Tue, Oct 6, 2020 12:59 AM

Maybe you can use SQlite3 in a persistent volume?

On Mon, Oct 5, 2020, 19:23 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

Maybe you can use SQlite3 in a persistent volume? On Mon, Oct 5, 2020, 19:23 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
PN
Pierce Ng
Tue, Oct 6, 2020 1:22 AM

On Mon, Oct 05, 2020 at 11:23:25PM +0100, Tim Mackinnon wrote:

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.

Hi Tim,

If you are familiar with Docker then starting a database server is easy that way. Assuming you pick a 'boring' product then what matters for your app is the quality of the database interface code on Pharo for that product. For PostgreSQL and MySQL no problem. I've not used Mongo itself nor Voyage so no comment.

If you neither want to run a separate database server nor roll your own writing out to Fuel etc, then you're looking at 'embedded' databases. For pure Smalltalk, Omnibase or SimplePersistence. If you are ok with something that uses FFI, then SQLite, Unqlite and probably others.

Personally I'd choose SQLite because it is boring - ubiquitous, high quality, and importantly unlike the pure Smalltalk and many embedded key-value databases there is a plethora of external tools that operate on SQLite databases which will help your debugging.

For SQL databases you can also use an ORM like Glorp or ReStore.

Finally there are also NoSQL-as-a-service like Google Firebase.

Many options. Great time sinks. :-) Have fun.

Pierce

On Mon, Oct 05, 2020 at 11:23:25PM +0100, Tim Mackinnon wrote: > 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. Hi Tim, If you are familiar with Docker then starting a database server is easy that way. Assuming you pick a 'boring' product then what matters for your app is the quality of the database interface code on Pharo for that product. For PostgreSQL and MySQL no problem. I've not used Mongo itself nor Voyage so no comment. If you neither want to run a separate database server nor roll your own writing out to Fuel etc, then you're looking at 'embedded' databases. For pure Smalltalk, Omnibase or SimplePersistence. If you are ok with something that uses FFI, then SQLite, Unqlite and probably others. Personally I'd choose SQLite because it is boring - ubiquitous, high quality, and importantly unlike the pure Smalltalk and many embedded key-value databases there is a plethora of external tools that operate on SQLite databases which will help your debugging. For SQL databases you can also use an ORM like Glorp or ReStore. Finally there are also NoSQL-as-a-service like Google Firebase. Many options. Great time sinks. :-) Have fun. - PostgreSQL - https://github.com/svenvc/p3 - MySQL - https://github.com/pharo-rdbms/Pharo-MySQL - Omnibase - https://github.com/sebastianconcept/OmniBase - SimplePersistence - https://github.com/seandenigris/Simple-Persistence - SQLite - https://github.com/pharo-rdbms/Pharo-SQLite3 - Unqlite - https://github.com/mumez/PunQLite - Glorp - https://github.com/pharo-rdbms/glorp - ReStore - https://github.com/rko281/ReStoreForPharo - Firebase - https://github.com/psvensson/firebase-st - Choose Boring Technology - http://boringtechnology.club/ Pierce
JV
Jonathan van Alteren
Tue, Oct 6, 2020 8:40 AM

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

jvalteren@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

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 jvalteren@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
TM
Tim Mackinnon
Tue, Oct 6, 2020 12:47 PM

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.

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

jvalteren@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

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. 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* > > jvalteren@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
J
jtuchel@objektfabrik.de
Tue, Oct 6, 2020 1:37 PM

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/

jvalteren@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:jtuchel@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

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/ >> >> jvalteren@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:jtuchel@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
SP
Sean P. DeNigris
Tue, Oct 6, 2020 2:34 PM

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

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
EM
Esteban Maringolo
Tue, Oct 6, 2020 6:04 PM

Hi Pierce,

On Mon, Oct 5, 2020 at 10:22 PM Pierce Ng pierce@samadhiweb.com wrote:

On Mon, Oct 05, 2020 at 11:23:25PM +0100, Tim Mackinnon wrote: Many options. Great time sinks. :-) Have fun.

<snipped options>

This made my day. Thank you :-)

Esteban A. Maringolo

Hi Pierce, On Mon, Oct 5, 2020 at 10:22 PM Pierce Ng <pierce@samadhiweb.com> wrote: > On Mon, Oct 05, 2020 at 11:23:25PM +0100, Tim Mackinnon wrote: > Many options. Great time sinks. :-) Have fun. > > <snipped options> > - Choose Boring Technology - http://boringtechnology.club/ This made my day. Thank you :-) Esteban A. Maringolo
EA
Esteban A. Maringolo
Tue, Oct 6, 2020 6:22 PM

Hi Tim,

I think that the persistence you choose will depend heavily on a few things:

  • The complexity of the objects graphs in your domain models
  • This architecture of your system
  • How these objects/data is acceded (Atomically/In clusters)

In any case, for a lightweight solution you go the Fuel path, or something using SQLite.

I have a GLORP based application (small, ~40 persisted classes), SQLite is so lightweight that I run my SUnit tests creating the whole database on disk from scratch on setUp and destroying it on tearDown), and only run it against the production backend (PostgreSQL) before deploying, but even this is happening less frequently since I'm confident that things will work the same on both.

OTOH I'm finding that ORMs are burden, and unless you need to work with an existing schema or you really want to use an RDBMS, you might be better off avoiding them. I've been using ORMs for almost two decades, so that's still my default choice, but I feel winds of change here :-)

Regards!

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Hi Tim, I think that the persistence you choose will depend heavily on a few things: - The complexity of the objects graphs in your domain models - This architecture of your system - How these objects/data is acceded (Atomically/In clusters) In any case, for a lightweight solution you go the Fuel path, or something using SQLite. I have a GLORP based application (small, ~40 persisted classes), SQLite is so lightweight that I run my SUnit tests creating the whole database _on disk_ from scratch on setUp and destroying it on tearDown), and only run it against the production backend (PostgreSQL) before deploying, but even this is happening less frequently since I'm confident that things will work the same on both. OTOH I'm finding that ORMs are burden, and unless you need to work with an existing schema or you really want to use an RDBMS, you might be better off avoiding them. I've been using ORMs for almost two decades, so that's still my default choice, but I feel winds of change here :-) Regards! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
GC
Gabriel Cotelli
Tue, Oct 6, 2020 7:03 PM

If you want to use docker there's https://github.com/ba-st/docker-pharo and others that I don't remembar now that provides the basics. You have some examples in https://github.com/ba-st/docker-pharo/blob/master/docs/Examples.md .

We're deploying our apps as docker containers so ask any question if you have doubts.

On Tue, Oct 6, 2020 at 9:48 AM Tim Mackinnon tim@testit.works wrote:

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.

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

jvalteren@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

If you want to use docker there's https://github.com/ba-st/docker-pharo and others that I don't remembar now that provides the basics. You have some examples in https://github.com/ba-st/docker-pharo/blob/master/docs/Examples.md . We're deploying our apps as docker containers so ask any question if you have doubts. On Tue, Oct 6, 2020 at 9:48 AM Tim Mackinnon <tim@testit.works> wrote: > 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. > > 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* > > jvalteren@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 > > >