[Cuis-dev] ODB options

[Luciano Notarfrancesco]

Isn’t anyone using the image segments primitives for persistence? Long time
ago I found them useful for storing relatively simple objects (images,
maps, sound data) that were too big to have fully loaded in memory, so
would load them only when required and keep them on a weak reference. One
advantage of using image segments is that loading from disk into the image
is really really fast, because its just a chunk of object memory.

On Tue, Dec 17, 2024 at 15:31 H. Hirzel via Cuis-dev <cuis-dev at lists.cuis.st>
wrote:

>
>
> On Sun, Dec 15, 2024 at 7:54 PM Juan Vuletich via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> On 12/14/2024 11:40 AM, Hilaire Fernandes via Cuis-dev wrote:
>>
>> Hi !
>>
>> What are our options for ODB?
>>
>> Experimented with ReferenceStream, but I have a mixed experience so far,
>> hard to control what is and is not persisted.
>>
>> Thanks
>>
>> -- http://mamot.fr/@drgeo
>>
>>
>> Norbert Hartl presented Soil ( https://github.com/ApptiveGrid/Soil )
>> this year at the FAST Smalltalks conference in Mar del Plata. I suggest
>> consider porting it to Cuis.
>>
>
> The "Soil" OODB needs the Fuel serialization mechanism which comes with
> Pharo. A Squeak port is regularly maintained by Max Leske.
> https://github.com/theseion/Fuel
>
> A Fuel port to Cuis would be useful thus replacing the ReferenceStream.
> And maybe that would be enough for a start.
> Maybe start with a simple database
> See
> https://norbert.hartl.name/blog/2023-01-14_object-serialization.html
> and
>
> https://norbert.hartl.name/blog/2023-01-07_byob-build-your-own-database.html
>
> In an earlier post I advocated going against a 'home grown solution' but
> this one actually would rely on the Fuel serializer, proven and well tested
> code.
>
> A problem I see and I do not know how it will be solved is that Fuel is
> from Pharo version to Pharo version incompatible with the previous one.
> See https://github.com/theseion/Fuel?tab=readme-ov-file#pharo--12
> Would need more investigation of what this actually means.
>
>
>> There are other earlier object databases for the Squeak / Cuis / Pharo
>> family. I can remember Magma. I believe there are others.
>>
>> Some googling and a search in our email list archives may be of help.
>>
>> Possibly useful:
>> http://onsmalltalk.com/squeak-smalltalk-and-databases
>> https://wiki.squeak.org/squeak/512
>>
>
> It might be useful to outline a sequence of solutions (as outlined in the
> links given by Juan)  from simple to complex that can be developed in
> parallel during 2025 so that the Dynabook development is not hampered too
> much by the need to develop persistence mechanisms.
>
> In my app I just focus on Media types in terms of persistency (Picture
> files at the moment -- around 1000, will grow ) and String data and
> OrderedCollections of Integers referencing the pictures by number. I can
> manage to keep this in a single tree kept in a singleton at the moment.
> And that will be good enough for 2025. Later I also would like to have a
> persistency solution in Cuis.
>
> -- Hannes
>
>
>>
>>
>> Cheers,
>>
>> --
>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241217/ab5cba10/attachment-0001.htm>