Data Tables Structure

[meatballs]

I'm starting to think about a data tables structure that would work nicely with the atomic module and form the basis of a replacement for the ORM app...

Assuming that an atom is a portable class and can therefore be serialised, there could be single table to hold all atoms - with an id column (probably a uuid) and a simple object object column to hold the serialised atom.

In order to search for atoms, we'd then have other 'indexing' tables - where attribute values of those atoms become columns in the table that can be searched and there's a further text column holding the uuid.

We'd probably need something within an atom to indicate attributes which are actually relationships to other atoms.

We'd also need a table for media object, similar to the atoms table, and a mechanism within the atom for referencing those too.

[rhurlbatt]

I can vouch for the simple object storage. I did some testing with my data tables and here are the results fetching 600 rows from one table of about 1200 - timing is in seconds of Client-Server-Client. No Media objects included. The reason I started this the app was taking too long to load.

Lazy Search with linked row: 38.321
Lazy Search with row ID: 6.043
Unpacked Search with linked row: 109.201
Lazy Search with row ID - No Linked Columns: 2.352
Unpacked Search with row ID - No Linked Columns: 2.808

These tables had about 30 columns of data and about 8 linked columns before I repacked it to simple objects.
I changed all the linked columns to row_ID strings and an identifying name string.

As you can see the performance improvement of searching and returning is quite significant and I think that this 'little' project is massively beneficial.

One thing that was frustrating was dealing with datetime objects - having these serialised automatically would be amazing.

[meatballs]

Nice to have some hard data!

The serialiser in anvil extras (only on the dev branch at the moment) already handles datetime columns.