|
On 2015-01-20, 3:51 AM, "OC" wrote:
Chuck,
Yes, modifying the database seems a little dangerous here.
Why should it be?
Just concerns around locking, multiple instances, and multiple versions. You seem to have that in hand.
I probably am missing something of importance, but it seems to me the danger of, say, removing a column which really should have remained is exactly same as the (ever-present) danger of removing an EO which really should have remained.
(Which reminds me of the very strange affair of lost EOs which we debated in the "Objects disappeared" thread at the beginning of December.)
As for potential synchronization issues, well, of course any changes in DB schema must be locked to allow only one instance doing that anyway. (Actually, at the moment, I have to restart my application to change the schema; that's not good, but so far
I haven't been able to find a solution to my problem with transaction setting :/ )
What am I overlooking?
Take a look at our Virtual Tables framework:
Would it help? I have found a comment that
in order to query the data, all the required data needs to be faulted in
which seems to me would bump into the same problems we have with our original implementation:
"Unfortunately, the optimization code is actually in SiteMaker, not in the VirtualTables framework Itself”
I’d forgotten how Sacha did that. If you migrated the optimizations, it might perform well enough for your needs, I can’t say.
Originally, I have solved this through a BLOB, which contains a serialized NSDictionary, which contains all the dynamic attributes by-name.
That works reasonably well, but we bumped into grave efficiency problem filtering such tables: to fetch only items whose attribute 'foo' matches 'John*', we can't do SQL SELECT; instead we have to fetch the whole table, decode all the BLOBs, and filter
by the results. That proved a show-stopper.
There's another potential problem with
our Virtual Tables framework. It allows you to create new EO-like entities and objects on the fly. These can't have any code, but have full KVC access
-- my EOs alas are pretty complex, and not being able to implement their code would be rather difficult. Whilst theoretically I might be able to overcome this problem using Groovy traits, I have tested those, and so far am less than impressed -- they does
not seem to be quite reliable, alas :/
That seems to rule out VT as a potential solution then. :-(
Chuck
Thanks a lot,
OC
|