Return-Path: X-Original-To: apmail-cayenne-dev-archive@www.apache.org Delivered-To: apmail-cayenne-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D2D73DEA0 for ; Sun, 11 Nov 2012 10:37:41 +0000 (UTC) Received: (qmail 83593 invoked by uid 500); 11 Nov 2012 10:37:41 -0000 Delivered-To: apmail-cayenne-dev-archive@cayenne.apache.org Received: (qmail 83461 invoked by uid 500); 11 Nov 2012 10:37:41 -0000 Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cayenne.apache.org Delivered-To: mailing list dev@cayenne.apache.org Received: (qmail 83322 invoked by uid 99); 11 Nov 2012 10:37:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Nov 2012 10:37:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.78.103.231] (HELO vorsha.objectstyle.org) (208.78.103.231) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 11 Nov 2012 10:37:34 +0000 Received: (qmail 13267 invoked from network); 11 Nov 2012 10:40:47 -0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by localhost with SMTP; 11 Nov 2012 10:40:47 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving "merge" package to cayenne-tools in 3.2? From: Andrus Adamchik In-Reply-To: Date: Sun, 11 Nov 2012 13:37:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE1F03F-4B37-4EB6-BF53-64808F98E339@objectstyle.org> References: <6513E680-491F-41E1-B7E3-384CF21AE1CB@objectstyle.org> <6467E9DA-021F-4E34-B192-BC6946F15849@pvv.ntnu.no> To: dev@cayenne.apache.org X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org 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 = wrote: >> However, if it is in a separate jar or not is not important. >=20 > 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. >=20 > Andrus >=20 > On Nov 10, 2012, at 10:44 PM, Tore Halset wrote: >=20 >> Hello. >>=20 >> 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. >>=20 >> However, if it is in a separate jar or not is not important. >>=20 >> Regards, >> Tore Halset. >>=20 >> On Nov 10, 2012, at 5:14 PM, Andrus Adamchik = wrote: >>=20 >>> 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). >>>=20 >>> "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.=20 >>>=20 >>> Any reason to keep it in the runtime framework? >>>=20 >>> Andrus >>>=20 >>> 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.=20 >>=20 >>=20 >=20 >=20