I think Voyage with its connection to Mongo is somewhat more palatable to some
companies - however I did forget to mention Glorp of course - which does map
directly to a SQL database.
Not to dis Gemstone in anyway (I do wish OO db's had gained more traction in
the past, they are still glorious
Agreed that larger orgs and BI teams likely slant toward SQL. But GemStone
and Voyage/Mongo wouldn’t address that either. An export from a Soil,
GemStone or Mongo db, into a SQL db should address the BI tools.
On Sun, Feb 18, 2024 at 4:35 PM Tim Mackinnon wrote:
> I wasn't particularly advocatin
I wasn't particularly advocating any path - but have observed that in larger
orgs its a more difficult discussion to tread a different path (rightly or
wrongly) - you have to cope with BI teams, who know mainly SQL based tools and
equivalently support teams who know the same - and if in that wo
Tim,
What is the thinking behind “Finally you might need something more
enterprise and then Gemstone or Voyage…”?
Is it the maturity level of Soil codebase vs. these others? Or is it a
belief that a database has to be a complex separate piece of engineering
(therefore best outsourced).
Yanni
On
I think Ross (and what Norbert said) nicely alludes to the path people follow -
for really simple persistence, Fuel or simple image saving give you an instant
solution. The next step (assuming no real concurrency issues) are what Sean has
maintained - something that gives you rolling snapshots a
Hi Russ,stay tuned, we are preparing a 0.1 release for Soil before or at the time of pharo12 release. With 0.1 we will document how to use it. If you use STON it will be similar because if you do db := Soil path: ‚mydb‘.db initializeFilesystem.txn := db newTransaction.txn root: yourModelRoot.txn co
Norbert,
I'm very interested to investigate Soil. Do you have examples on how to
use Soil?
I currently use a STON persistence model. My current approach to my model
is structured specifically to make STON full save and restores simple...
- Wrapper Class which contains a collection of high level
The approach as I understand is simple and valuable until you face concurrency.
Nothing in SimplePersistence prevents your data from becoming corrupt in a
concurrent situation. I agree that when you start a project you almost never
face concurrency because the odds are way too low to have two th
I’m happy to answer any questions about Simple Persistence. It is a nice
framework around (potentially any) serializer. It’s meant to be pluggable but
currently uses Fuel out of the box. You just tell it what classes to persist
and then create two methods per class to handle materialization/seri
Let me check it out.
It’s not too late. This is a fun “scratch my own itch” project.
So there are no deadlines looming or anything..
> On Jan 31, 2024, at 9:20 AM, Tim Mackinnon wrote:
>
> Sergio - might be too late now, but I haven't seen anyone mention Sean's
> solution - https://github.
Sergio - might be too late now, but I haven't seen anyone mention Sean's
solution - https://github.com/seandenigris/Simple-Persistence (I think it uses
Fuel under the hood, but its a nice simple solution)
Tim
On Thu, 18 Jan 2024, at 4:48 AM, sergio ruiz wrote:
> I have been in the relational d
Hi Sergio,
I have used Fuel to good effect to store a tree of objects (with all
interlinkages).
Saving:
saveTo: aFileOrName
| aFileName |
aFileName := aFileOrName fullName.
FLSerializer serialize: self toFileNamed: aFileName
Loading:
loadFrom: aFileOrFileName
| new |
new := FLMaterializer
Hi Sergio,
I added a Movies demo, using a Soil database. There was a previous
Accounting demo that had two versions (in memory database and Soil
database) from which I based the new demo. I like the Movie demo because it
is simple yet complex enough. I suspect the Accounting demo is too
complicate
Sergio,
I would go with STON, as advised by Norbert (I don't have experience
with Soil). One of the nice things of STON is that you can use whatever
DVCS you like to versionate your data. For example, we locally use
Fossil, while most people prefer Git.
STON is super versatile! As an example
The idea is, I have been a software engineer for the past three decades.
I REALLY love my profession (even though now, it’s pretty much sitting in
meetings all day), but I love it.
I have a few projects I always wanted to do, because I just want to do them
because they are useful to me.
I have
Can you sketch out the complexity aspects of your five projects? Is this
all for learning, or are they “production” applications? Do you want to
gain experience with different ways to persist data, or are you just
thinking that you have to use different ways due to project complexity? It
might be t
> Am 18.01.2024 um 14:54 schrieb sergio ruiz :
>
> Using this Will my links remain viable using this method?
>
> Meaning that an event has a theater. That theater is also in the
> OrderedCollection of Theaters.
>
> If the name of he theater changed in the Theaters collection, will that name
I figured Gemstones would be SUPER heavy handed for this application, but I
have a list of five projects, each increasing in complexity that I want to
launch and document. So, sooner or later, I will need a more robust solution.
Thanks!
> On Jan 18, 2024, at 8:26 AM, Norbert Hartl wrote:
>
Using this Will my links remain viable using this method?
Meaning that an event has a theater. That theater is also in the
OrderedCollection of Theaters.
If the name of he theater changed in the Theaters collection, will that name
change occur in the event theater object?
After bringing these
OOH.. I like this idea.
I’ll do a quick test on this and see if it works as expected..
For now, I want to store the data in the image.
The trick is, I like to start with a fresh image every few days. So, I’d like
to open a new Pharo, pull the source code, then pull the data.
Thanks!
>
> If
I think it depends how many objects you have and what your consistency
requirements are.
> Am 18.01.2024 um 05:48 schrieb sergio ruiz :
>
> I have been in the relational database world for decades. One of the things
> that is super simple is backing up and restoring data.
>
> Sometimes, it mak
+1 for Fuel, see here https://github.com/theseion/Fuel
CheersDavide
On Thursday, January 18, 2024 at 09:37:21 AM GMT+1, Todd Blanchard via
Pharo-users wrote:
You want to look at Fuel, a serialization library.
Sent from my iPhone
On Jan 17, 2024, at 9:49 PM, sergio ruiz wrote:
You want to look at Fuel, a serialization library.
Sent from my iPhone
> On Jan 17, 2024, at 9:49 PM, sergio ruiz wrote:
>
> I have been in the relational database world for decades. One of the things
> that is super simple is backing up and restoring data.
>
> Sometimes, it makes it makes s
Sergio,
If you are keeping data in a Pharo image then you could just save the image
instead of using STON. Alternatively, you could model your data in an
Application class with three instance variables: theaters, movies, and events.
Then you could dump the root application object and STON shoul
24 matches
Mail list logo
