cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: Cayenne and migrations
Date Thu, 09 Feb 2017 23:50:01 GMT
We use liquibase to execute SQL combined with special liquibase functions to run groovy/Java
classes which are needed to do more complex migrations in code (within the Cayenne model).
Those complex migrations might include adding new data to the DB or modifying existing records
in ways that SQL is too cumbersome for.

Where we come unstuck is that if a bug was introduced 20 versions ago, it can be hard to recover.
Phabricator (an open source project management, code review solution written by Facebook)
has a neat feature: it verifies your model each time you run the upgrade. So if an index is
missing, then the code will just add it. If a collation is wrong, then it is fixed.

I'd be pleased to have something similar as a library for Cayenne. Obviously we'd need to
add meta-data to the model like indices, but having a 'please make the DB look like my model'
feature would be great. Obviously it isn't going to be able to fix everything, but for non-destructive
changes like indices it would be really useful.

Ari


On 10/2/17 9:41am, Andrus Adamchik wrote:
> FWIW, the workflow I am using is "DB-first", and Cayenne 4.0 is providing the tools to
make it practical and mostly automated:
> 
> 1. Use a migration tool like Flyway or Liquibase to code your migrations in SQL (even
more so when wrapped in bootique-liquibase / bootique-flyway).
> 2. Run cdbimport from Maven/Ant/Gradle to sync Cayenne model from DB.
> 3. In the modeler fix any object naming discrepancies, map custom value objects, map
inheritance.
> 4. Run cgen to sync Java classes from Cayenne model
> 5. Rinse and repeat.
> 
> Can someone please explain the workflow with ERX|cayenne migrations? What are the advantages
over the approach above? Does it handle data migrations or only the schema?
> 
> Andrus
> 
> 
>> On Feb 10, 2017, at 7:06 AM, John Huss <johnthuss@gmail.com> wrote:
>>
>> I pushed the changes I had pending - there was more than I thought.
>>
>> I'm fine with it going in, but I'm not sure that the community agrees.
>> Since this can live as an independent project / jar there isn't really a
>> need to merge it into the main cayenne repo.  But if we are going to keep
>> it separate we should move it to github or something where participation is
>> easier.
>>
>> Another issue - I'm pretty sure this won't build or run against cayenne's
>> master anymore due the to refactoring of DbMerger stuff.  But I haven't
>> tried.
>>
>> On Thu, Feb 9, 2017 at 1:14 PM Musall, Maik <maik@selbstdenker.ag> wrote:
>>
>>> Hi John,
>>>
>>> how do you (and everyone else) feel about including this in the main repo
>>> after polishing?
>>>
>>> I'm working with Hugi here on a project and would like to continue using
>>> this style of
>>> migrations because our entire environment is geared towards it. I'd love
>>> for this to be in
>>> the main cayenne repo so we can submit our improvements.
>>>
>>> Maik
>>>
>>>> Am 09.02.2017 um 15:59 schrieb John Huss <johnthuss@gmail.com>:
>>>>
>>>> It's current except for a single small change.  I seem to have lost the
>>>> push url, so I need to get it working again to update it.  But it would
>>> be
>>>> fine for playing with as is.
>>>>
>>>> On Thu, Feb 9, 2017 at 9:45 AM Hugi Thordarson <hugi@karlmenn.is> wrote:
>>>>
>>>>> Hi John,
>>>>> that’s very interesting. Is your current work public or is the most
>>> recent
>>>>> public work in the SVN-repo I mentioned?
>>>>>
>>>>> Cheers,
>>>>> - hugi
>>>>>
>>>>>
>>>>>> On 9. feb. 2017, at 15:36, John Huss <johnthuss@gmail.com>
wrote:
>>>>>>
>>>>>> I'm developing and using cayenne-migrations. It works fine for me
and
>>>>> has a
>>>>>> very similar approach to ERXMigrations.  I don't think others are
using
>>>>> it
>>>>>> though.  It has the advantage of being able to auto-generate the
>>>>> migration
>>>>>> code from your cayenne model (DataMap), where I think the others
>>> require
>>>>>> hand coding.  On the other hand, sometimes having all pure SQL
>>> statements
>>>>>> instead of mostly java code is useful.  Good luck!
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Thu, Feb 9, 2017 at 9:15 AM Michael Gentry <mgentry@masslight.net>
>>>>> wrote:
>>>>>>
>>>>>>> Hi Hugi,
>>>>>>>
>>>>>>> We manage schema changes outside of Cayenne using Flyway (could
also
>>> use
>>>>>>> Liquibase).  Any schema changes we make are updated by hand in
Cayenne
>>>>>>> Modeler.  This works fairly well for us and fits in with our
automated
>>>>>>> builds/etc.  Perhaps not the answer you were looking for, though!
>>>>>>>
>>>>>>> mrg
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 9, 2017 at 9:21 AM, Hugi Thordarson <hugi@karlmenn.is>
>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all.
>>>>>>>> In EOF/WOnder we have the most swesome ERXMigrations to manage
>>> changes
>>>>> in
>>>>>>>> the data model between versions, i.e. upgrades of the schema
(and
>>>>>>>> downgrades, if applicable).
>>>>>>>>
>>>>>>>> I see that some years ago there was discussion of an API
to handle
>>> this
>>>>>>> in
>>>>>>>> Cayenne ( http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-
>>>>>>>> migrations/ ). but how’s the situation today? Is there
something
>>> in/for
>>>>>>>> Cayenne to do this, and if not, what tools are people using
to manage
>>>>>>>> versioning of their DB schemas?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - hugi
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> 

-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Mime
View raw message