Re: Cayenne and migrations

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

Re: Cayenne and migrations

> 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? Mainly schema migrations. I think the advantages are: 1) Cross-database support from a single representation. So you can run

Re: Cayenne and migrations

> 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). "even more so" -> "especially easy to run" > On Feb 10, 2017, at 9:41 AM, Andrus Adamchik wrote: > > FWIW, the

Re: Cayenne and migrations

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

Re: Cayenne and migrations

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

Re: Cayenne and migrations

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

Re: Cayenne and migrations

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 wrote: > Hi John, > that’s very interesting. Is your

Re: Cayenne and migrations

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 wrote: > > I'm developing and using cayenne-migrations. It works fine for me and has a >

Re: Cayenne and migrations

Thanks Michael, we might look into that. - hugi > On 9. feb. 2017, at 15:15, Michael Gentry 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 >

Re: Cayenne and migrations

Yeah, all of our migration scripts are hand-coded SQL that we let Flyway then manage. We don't have the option of having the application run the migration scripts. We have to get one of our DBAs to do it using an admin account so they can create/drop/etc anything required, so we have set them up

Re: Cayenne and migrations

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

Re: Cayenne and migrations

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

Cayenne and migrations

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 (

Re: Using my own ObjectContext class

Thanks Nikita! - hugi > On 9. feb. 2017, at 10:21, Nikita Timofeev wrote: > > Hi Hugi, > > The "official" way to override newContext() result is to implement > your own ObjectContextFactory and inject it via custom Module. > > You can do it like this: > >

Using my own ObjectContext class

Hi all, what is the proper way to have ServerRuntime.newContext() return my own implementation of ObjectContext? (inheriting from DataContext). Any reason why that would be discouraged? Cheers, - hugi