> However, if it is in a separate jar or not is not important. Yeah, good point. I guess I'll proceed and attempt to consolidate everything related to schema and metadata manipulation in 'tools'. Kind of like we consolidated project saving/loading/upgrading/validation functions under cayenne-project in 3.1.
Andrus On Nov 10, 2012, at 10:44 PM, Tore Halset <hal...@pvv.ntnu.no> wrote: > Hello. > > We use the merge package in our web applications during startup to perform > some not-destructive database migration. Like adding fields, expanding fields > and so on. This makes database migration a lot easier for us since most of it > is done automatically. For us, this is more useful than having merge in the > modeler. > > However, if it is in a separate jar or not is not important. > > Regards, > Tore Halset. > > On Nov 10, 2012, at 5:14 PM, Andrus Adamchik <and...@objectstyle.org> wrote: > >> I wonder we should move "merge" package to cayenne-tools from cayenne-server >> in 3.2. To me schema manipulation operations are somewhat separate from the >> runtime part. (So DbLoader and DbGenerator are also candidates for a similar >> move, maybe later). >> >> "merge" main use seems to be from the Modeler, which imports >> cayenne-tools.jar. And of course cayenne-tools is available via Maven, and >> other Cayenne distribution channels. >> >> Any reason to keep it in the runtime framework? >> >> Andrus >> >> P.S. I am also looking at much more glaring modularity issues with Cayenne >> (the whole "unpublished" thing that we discussed on many occasions), but >> don't have any proposals yet, so figured we'd start with things more >> confined in scope. > >
