On 14 Jan 2015, at 1:56 am, OC <o...@ocs.cz> wrote: > On 13. 1. 2015, at 5:33, Paul Hoadley <pa...@logicsquad.net> wrote: >> On 13 Jan 2015, at 12:06 pm, OC <o...@ocs.cz> 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
