Tim saving in STON is also nice :). S
> On 6 Oct 2020, at 22:41, Tim Mackinnon <tim@testit.works> wrote: > > Gosh - this is proving much more interesting than I had imagined, and I’m > getting lots of useful input, so I double appreciate the time and thoughts > from everyone. > > I probably should have said that my "super awesome idea" is just a little > flashcard spelling app for my daughter (and possibly a few friends in her > class) - so probably SimplePersistance will do in this case, however the > comments about making a persistence decision at the right moment are super > interesting - and as always, its about spotting the right moment to do that… > and ideally you have well factored code with ample tests that help you easily > move from the idea, to something more scalable or robust… however, move too > soon and you get bogged down with the details and you lose site of an MVP. > > It has been interesting hearing peoples thoughts on all of this… the turning > tide on ORM’s, the potential sweet allure of a NoSql (but can you query it > easily) - and then the overarching element of just setting this shit up > (where hopefully Docker steps in to make that bit at least easy). I suppose > this is where the Rails scaffolding was/is? such a jumpstart, you can get a > full thing going quite easily, and deploying seems relatively easy too… for > us in Smalltalk land, its still a bit too much work for my liking, compared > to the ease of getting an image and coding, and seeing it all work. It does > seem to be getting marginally better at least, but I do wish there was super > easy setup with all the pieces nicely in place so it was just your idea that > you could focus on… > > Anyway, that login screen… oh crap I have to write one of those… > > Tim > >> On 6 Oct 2020, at 20:56, jtuc...@objektfabrik.de wrote: >> >> 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 >> -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France
