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". > (b) I have to write basic Java code for each supported "version", which code > (could do about anything, but normally) just loads and executes a script > containing all the CREATE TABLE/ADD COLUMN/whatever SQL stuff needed; You can do it that way, though I prefer using the migrations API in code. Except for some edge cases (such as, for example, adding a new mandatory column to a table in which there are existing rows), you needn't have any SQL at all. On the other hand, I understand there are people who do what you describe above with external scripts. > (c) I have to write those scripts. Entity Modeler can generate SQL for you from a model. Alternatively, it will generate the initial migration code for you. For _changes_ to a model, you can limit generation to a selected entity, but there's always some manual intervention required for both approaches. You need to know what you're doing. > Then, WOnder migrations support keeps track of DB versions for me and makes > sure appropriate Java upgrade method of appropriate class for a given model > gets called (which normally means the appropriate script performed), based on > the current and desired DB version. Correct. > If my perception is right, this is definitely what I don't want here. Fair enough. > I don't need to manage different versions for lots of models. We don't use it that way either. It's just for an ongoing linear progression where a new "version" just means "the model changed". > (i) to determine the desired schema -- it is partially defined by static > model, partially defined by stuff stored in the database itself. So, the > first thing I need is to read some tables, and based on their contents to > create my schema dynamically. The thing is considerably more complex, but as > a simplified example, presume there's a T_SCHEMA table with C_TNAME, C_CNAME > and C_CTYPE columns; my code would read its contents, and for each row, it > would know in the dynamic scheme, the table whose name is stored in C_TNAME > should contain a column whose name is stored in C_CNAME and type in C_CTYPE. 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. -- 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
