Re: Model/DB synchronization (was: Migrations (was: ERXSQLHelper))
Re: Model/DB synchronization (was: Migrations (was: ERXSQLHelper))
- Subject: Re: Model/DB synchronization (was: Migrations (was: ERXSQLHelper))
- From: OC <email@hidden>
- Date: Tue, 20 Jan 2015 12:51:15 +0100
Chuck,
On 14. 1. 2015, at 1:12, Chuck Hill <email@hidden> wrote:
> Yes, modifying the database seems a little dangerous here.
Why should it be?
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:
> http://www.global-village.net/chill/gvc_frameworks
Would it help? I have found a comment that
> in order to query the data, all the required data needs to be faulted in
https://www.mail-archive.com/email@hidden/msg35887.html
which seems to me would bump into the same problems we have with our original implementation:
> 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
http://lists.apple.com/archives/webobjects-dev/2010/Mar/msg00124.html
-- 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 :/
Thanks a lot,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden