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: Ramsey Gurley <email@hidden>
- Date: Tue, 20 Jan 2015 15:43:01 -0700
I have postgres tables with millions of rows. Not BIG but not small either. Building an index on some of them takes minutes. Minutes where the table is locked.
Depending on your db, adding a column can require a full table copy. Again, minutes unless you have some high end SSDs.
I have this one column on Sybase I wanted to allow null. That's it. Just allow null. Sorry, that table is 360GB. We didn't have enough room left on the SAN to do it. Even if we did, it would have been locked hours to alter table.
Getting WO to sync model modifications live across multiple instances would be a total PITA, but that would probably be the easy part.
OC <email@hidden> wrote:
>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