Ok, the moment after I wrote this, I realized how deep this thing goes. To do what I want here would require seriously rewriting DbAdapter. This is much more effort than I am willing to invest now. So I am putting it on hold until we are ready to start a general modularity discussion.
Andrus On Nov 11, 2012, at 1:09 PM, Andrus Adamchik <[email protected]> wrote: >> 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 <[email protected]> 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 <[email protected]> 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. >> >> > >
