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: Paul Hoadley <email@hidden>
- Date: Wed, 14 Jan 2015 09:12:38 +1030
On 14 Jan 2015, at 1:56 am, OC <email@hidden> wrote:
> On 13. 1. 2015, at 5:33, Paul Hoadley <email@hidden> wrote:
>> On 13 Jan 2015, at 12:06 pm, OC <email@hidden> wrote:
>>> Now I have re-readed the docs a couple of times, and it seems to me
>>> (a) I have to mark different schemas as "versions";
>>
>> It's really only conceptual. A "version" is just a "change to the model which I'm going to need to reflect in the database at the next deployment".
>
> Well right, but far as I understand, the version numbers are important to select the appropriate upgrade code, are they not?
Yes, though I think most people are using them in a simple progression. Change the model, add a new class (or maybe two), new classes get run at next deployment, repeat.
>> ... I prefer using the migrations API in code.
>
> If you mean e.g. adding columns through migrationTable.newXXXColumn(name,allowsNull) etc., that's what does not work for me. It consistently generates "alter table FOO null BAR TYPE" instead of "alter table FOO add column BAR TYPE".
I've seen that when I've forgotten to add the correct SQL plugin framework to the build path.
>> I agree that migrations is not going to help you with that. That sounds like a pretty unique use case. Out of curiosity, are you able to describe in greater depth what you're doing here? (That is, the actual nature of the application, or the problem you're solving. I understand your technical explanation, I just can't picture a use case for it.) It sounds very interesting.
>
> Well the gist is that some of my EOs have (along with normal ones) a set of user-defined attributes: the user can open an appripriate editor and set up something like "my auction will, along with the attributes which the application itself defines, also three VARCHAR attributes named 'foo', 'bar', and 'bax'; they will have four DECIMAL attributes named so-and-so, etc etc.". These things are stored in the database, and the application then allows to use the dynamic attributes the very same way one can use static ones (i.e., display them in forms/tables, edit their contents, filter by them, etc.)
>
> 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.
>
> Thus, now I have to implement all those dynamic attributes as table columns, so that I can (e.g.) use fetch qualifiers for them.
Thanks for describing that—very interesting. I think it would be safe to say that yours is a use case outside those for which migrations was originally designed. You might be able to beat the API into helping you out, but I think the pool of experience with using migrations to do anything like it is going to be pretty shallow. Good luck!
--
Paul Hoadley
http://logicsquad.net/
_______________________________________________
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