I have not had much fun transforming complex class structures into relational models.
Given an object myCurrentComplexObject it would seem a very common application requirement to persist and rehydrate it and all the structures within with single methods like myCurrentComplexObject.Persist(folderItem) and myCurrentComplexObject.Rehydrate(folderItem)
I assume persistence to a FolderItem as (JSON or binary) or to a database BLOB or CLOB.
What are the generally accepted smart ways to simplify this problem when using Xojo?
I would wager that the easiest and most reusable way to do this is to write the class’s properties out into a dictionary and then write a generic dictionary flattener that outputs the dictionary’s contents as a string; then, it reverse the process upon rehydration and the class uses it to fill in its properties.
This discussion is way old but … I still do not feel we have a production quality way to persist an arbitrarily complex object tree to disk and back into app memory again. The raw format is not that critical, JSON is good, but … it needs to rebuild a live object tree in a simple reliable manner.
Is there a commercial framework that we should be considering? This functionality is such a fundamental aspect of any app that I feel I am missing something, OR the Xojo group is missing something. Not sure I want to go build and debug such a moderately sophisticated thing, just for me. Delighted to re-imburse someone else’s efforts.
Thanks for your prompt reply. I have used Kem’s excellent bit of engineering but have struggled with some edge cases of: Enums, particular sequences of Types that cause confusion and (quite understandably given the origins of the code) a lack of documentation.
Bjorn at Einhuger has a neat solution with their XML/JSON Serialization module, but again not totally in sync with the latest XOJO framework.
Without partner conflict, I would expect such fundamental functionality to be provided by Xojo for all. If the raw code requires purchase from others, who may be more advanced, so be it, we shall pay. It feels like an opportunity for Xojo to consolidate best-practice into the core framework, much as Apple has done over time.
I suspect there is a common use case (like mine) where an Xojo app creates an object tree and populates data. It then persists the set of objects for however long, probably on disk (or logically similar technology), then rehydrates them for the next round of user updates, in the Xojo app.
This is probably my ignorance but an object such as myPersistentObject, with some limitations, should be serialisable and de-serializable in binary, XML or JSON.
I agree that one size fits all is not economically achievable, but a reliable production grade solution for one size fits most (common use cases) should be, don’t you think ?
It it were possible it would have been done 8 years ago when Aaron and I tried to actually write one.
It made perfect sense for a nifty new use case for Introspection (which was relatively new at the time)
And we ran into the things that make this impossible to do in a nice generic way.
And those things haven’t fundamentally changed in all that time.
Kem’s solution is close - but has edge cases like you mentioned
The IDE does persistence of your project
But its not “generic” in any way - each object basically implements an interface that writes either to binary or text
And all that code is custom per object
Making it “limited” in some ways brings you back to a code base not unlike Kem’s
First of all, I’m a novice in this discussion and … as Rumsfeld would say, I enjoy unknown unknowns. I do sense we might be discussing pragmatism versus perfectionism. If we were to look at a rather vanilla object tree, it could be represented in a JSON or XML style. It could also be represented as a xojo_binary (memory) object.
Whatever way the object existed in computer memory this morning, why cannot it re-emerge in computer memory this afternoon, having persisted through a pleasant siesta on disk?
Because the magic required to make it “re-emerge in computer memory this afternoon” doesn’t exist
And it CAN’T exist in a generic sense in the framework
Thats been my point all along
Within certain use cases serialization can be generalized. But there are limits. Hence Kem’s provided a solution that works for the cases he uses that covers the uses cases he needs. But it doesn’t cover 100% of the possible uses (as you wrote)
And the IDE contains all the code it needs to be able to write (serialize) your project to binary & text formats and read it back in and reconstitute your project
But its
a) not trivial
b) not generally usable for anything BUT the IDE (the code would all need to be revised for use in anything else)
I’d avoid pragmatic implementations that have limits
RTF support is an existing example of precisely this with attendant bug reports/feature requests despite the documented limitations
Over the years, and with many languages, I’ve had scenarios that I thought would benefit from being able to persist object state to disk, but never found a solution that was 100% perfect.
In every case I’ve returned to rebuilding the world from more simplistic truth, i.e. database records or simple data on disk. This has usually turned out to have been a better solution in the long-run as simpler data structures can be versioned and manipulated by other mechanisms with greater ease.
@Ian Ramsay, could you describe your specific use-case for serializing objects to disk?
I use serialize() in my PHP projects to cache data temporarily. Specifically I use it to pass a complex result object (containing several images and data-sets) to a separate process generating PDF files of the results. When serializing and unserializing, PHP calls two functions on the object (if they exists) __sleep and __wakeup and they are really useful.
In my Xojo projects I came across the need once when trying to pass data from the front-end UI to back-end calculation processes. I ended up doing this as JSON strings over IPC and then pass that string in the constructor. If a property exists I set it from JSON.