You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dmitry Gusev <dm...@gmail.com> on 2013/08/12 23:15:09 UTC
Liquibase for Tapestry5
FYI:
https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Liquibase for Tapestry5
Posted by Dmitry Gusev <dm...@gmail.com>.
Thanks for sharing this, Michael!
On Thu, Aug 15, 2013 at 1:00 AM, Michael Gentry <mg...@masslight.net>wrote:
> Hi Dmitry,
>
> Part of the risk-factor for us was that it takes about 1 week to do a
> production deployment here. If the application was running
> flyway.migrate() itself (reading the scripts out of the WAR) and there
> was an issue, it would be quite difficult to fix because we'd have to
> go through the deployment process again (because we'd have to generate
> a new WAR). Our environment just isn't that agile. Also, we'd have
> had to fight a battle with the DBAs and SAs to get our application's
> DB login account to have grants to create/drop/alter/etc tables and it
> just didn't seem worth the effort given the lack of agility. So we
> used Maven migrations and do a flyway.validate() on startup, but that
> can be turned off with a -D JVM parameter if needed. Our last
> production migration had over 100 scripts which ran without errors, so
> we manage the risk OK and the DBA loved the fact it was all automated
> and tested.
>
> For our non-production environments, we were able to get access to the
> admin DB accounts and set up Jenkins jobs to do automatic
> builds/migrations there. We could make these environments do
> flyway.migrate() on startup, but we wanted to keep them similar to the
> production environment and stuck with Maven for migration.
>
> Also, you mentioned doing rollbacks. We learned the hard way that
> MySQL DDL is not transactional and cannot be rolled back. We now do
> all DDL (create/drop/alter/etc) one-per-migration in case there is an
> issue. Flyway runs each migration in a transaction, so we only have
> to repair the one DDL that gave an error (any previous migrations
> succeeded). A bit ugly, but functional.
>
> Thanks,
>
> mrg
>
>
> On Wed, Aug 14, 2013 at 10:31 AM, Dmitry Gusev <dm...@gmail.com>
> wrote:
> > Hi,
> >
> > I think this is a good point to only check if migrations applied if your
> > risks are high.
> >
> > But if something went wrong with migration -- it should be rolled back
> and
> > simply won't apply.
> > So in both cases your application won't be started, whether you stopped
> > application manually and applied migration from plugin or if you run it
> > during application start -- isn't it?
> >
> > It is great if you have direct access to your database, like, via public
> IP
> > or VPN.
> > In this case you can do some migrations even without updating your
> codebase
> > and without restarting your app, just using plugins.
> >
> > I'm also using https://github.com/tlberglund/gradle-liquibase-plugin in
> > some cases where I have direct database access. But I mostly use it to
> > generate changesets from database schema so I don't have to write them
> > manually (I prefer setting <property name="hibernate.hbm2ddl.auto" value=
> > "update"/> for my development machine so that hibernate updated my db
> > schema first, so I don't even run liquibase on my development machine --
> > only on QA, Live environments with few exceptions when it is easier to
> > quickly write changeset and apply it using the plugin).
> >
> > The reason I choose to use automatic migrations in my recent projects is
> > that I use PaaS hosting environments like OpenShift and Jelastic and you
> > don't always have direct access to database there.
> >
> > For instance, with OpenShift, deployment is done by simply pushing new
> code
> > to git repo. I like that if I put new migrations in commit -- they will
> be
> > applied on application rebuild-restart. Of course I can SSH to remote
> > OpenShift instance and apply migrations manually -- for my projects this
> is
> > not productive, because I may doing 3-to-5 redeploys per day and some of
> > them may include db migrations.
> >
> > The same with Jelastic, I don't have SSH access to remote instances, but
> I
> > may buy public IP to have db access. But for the same reason of often
> > deploys I prefer to run migrations from within the cloud during
> application
> > start. And it works well for me so far.
> >
> >
> >
> > On Wed, Aug 14, 2013 at 5:22 PM, Michael Gentry <mgentry@masslight.net
> >wrote:
> >
> >> Hi Dmitry,
> >>
> >> Like Borut, we have many Maven profiles set up to do Flyway migrations
> >> in all of our environments and have set up our DBAs with Maven/etc in
> >> order for them to do our production migrations. On the Tapestry side,
> >> our AppModule has an @Startup method that does a Flyway validate() to
> >> ensure the schema is up-to-date or it throws an exception and the
> >> application fails to start. We initially thought about having the
> >> @Startup do the Flyway migrate(), too, but thought that might be a bit
> >> too risky, so we stuck with Maven.
> >>
> >> mrg
> >>
> >>
> >> On Wed, Aug 14, 2013 at 5:54 AM, Dmitry Gusev <dm...@gmail.com>
> >> wrote:
> >> > Just curious, and how do you deliver your migrations to target
> >> > environments, like production?
> >> >
> >> > On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <
> borut.bolcina@gmail.com
> >> >wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> no reusable modules at the moment, nor any integration, as we use the
> >> >> flyway as a maven plugin. I do see a potential use, but have no clear
> >> >> vision on how to use the auto-migration in a more complex
> >> >> development/runtime environments. Will have to dedicate some time
> into
> >> it
> >> >> and discover safe and clear paths in development cycles in a small
> >> >> development team.
> >> >>
> >> >> There is a live #Tapestry IRC channel, interesting...
> >> >>
> >> >> Regards,
> >> >> borut
> >> >>
> >> >>
> >> >> 2013/8/14 Dmitry Gusev <dm...@gmail.com>
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > It seems Flyway is popular among tapestry users, we've discussed it
> >> >> > yesterday on the #tapestry IRC channel.
> >> >> >
> >> >> > It seems (the only?) advantage of Flyway against Liquibase is that
> you
> >> >> can
> >> >> > run custom Java code during migrations.
> >> >> >
> >> >> > Do you have any reusable modules or, maybe, best practices how you
> use
> >> >> > Flyway with tapestry?
> >> >> >
> >> >> > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <
> >> borut.bolcina@gmail.com
> >> >> > >wrote:
> >> >> >
> >> >> > > Nice Dmitry!
> >> >> > >
> >> >> > > I (we) use Flyway for database migrations, but it is always nice
> to
> >> >> see a
> >> >> > > new Tapestry module!
> >> >> > >
> >> >> > > Regards,
> >> >> > > borut
> >> >> > >
> >> >> > >
> >> >> > > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
> >> >> > >
> >> >> > > > FYI:
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
> >> >> > > >
> >> >> > > > --
> >> >> > > > Dmitry Gusev
> >> >> > > >
> >> >> > > > AnjLab Team
> >> >> > > > http://anjlab.com
> >> >> > > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Dmitry Gusev
> >> >> >
> >> >> > AnjLab Team
> >> >> > http://anjlab.com
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Dmitry Gusev
> >> >
> >> > AnjLab Team
> >> > http://anjlab.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Liquibase for Tapestry5
Posted by Michael Gentry <mg...@masslight.net>.
Hi Dmitry,
Part of the risk-factor for us was that it takes about 1 week to do a
production deployment here. If the application was running
flyway.migrate() itself (reading the scripts out of the WAR) and there
was an issue, it would be quite difficult to fix because we'd have to
go through the deployment process again (because we'd have to generate
a new WAR). Our environment just isn't that agile. Also, we'd have
had to fight a battle with the DBAs and SAs to get our application's
DB login account to have grants to create/drop/alter/etc tables and it
just didn't seem worth the effort given the lack of agility. So we
used Maven migrations and do a flyway.validate() on startup, but that
can be turned off with a -D JVM parameter if needed. Our last
production migration had over 100 scripts which ran without errors, so
we manage the risk OK and the DBA loved the fact it was all automated
and tested.
For our non-production environments, we were able to get access to the
admin DB accounts and set up Jenkins jobs to do automatic
builds/migrations there. We could make these environments do
flyway.migrate() on startup, but we wanted to keep them similar to the
production environment and stuck with Maven for migration.
Also, you mentioned doing rollbacks. We learned the hard way that
MySQL DDL is not transactional and cannot be rolled back. We now do
all DDL (create/drop/alter/etc) one-per-migration in case there is an
issue. Flyway runs each migration in a transaction, so we only have
to repair the one DDL that gave an error (any previous migrations
succeeded). A bit ugly, but functional.
Thanks,
mrg
On Wed, Aug 14, 2013 at 10:31 AM, Dmitry Gusev <dm...@gmail.com> wrote:
> Hi,
>
> I think this is a good point to only check if migrations applied if your
> risks are high.
>
> But if something went wrong with migration -- it should be rolled back and
> simply won't apply.
> So in both cases your application won't be started, whether you stopped
> application manually and applied migration from plugin or if you run it
> during application start -- isn't it?
>
> It is great if you have direct access to your database, like, via public IP
> or VPN.
> In this case you can do some migrations even without updating your codebase
> and without restarting your app, just using plugins.
>
> I'm also using https://github.com/tlberglund/gradle-liquibase-plugin in
> some cases where I have direct database access. But I mostly use it to
> generate changesets from database schema so I don't have to write them
> manually (I prefer setting <property name="hibernate.hbm2ddl.auto" value=
> "update"/> for my development machine so that hibernate updated my db
> schema first, so I don't even run liquibase on my development machine --
> only on QA, Live environments with few exceptions when it is easier to
> quickly write changeset and apply it using the plugin).
>
> The reason I choose to use automatic migrations in my recent projects is
> that I use PaaS hosting environments like OpenShift and Jelastic and you
> don't always have direct access to database there.
>
> For instance, with OpenShift, deployment is done by simply pushing new code
> to git repo. I like that if I put new migrations in commit -- they will be
> applied on application rebuild-restart. Of course I can SSH to remote
> OpenShift instance and apply migrations manually -- for my projects this is
> not productive, because I may doing 3-to-5 redeploys per day and some of
> them may include db migrations.
>
> The same with Jelastic, I don't have SSH access to remote instances, but I
> may buy public IP to have db access. But for the same reason of often
> deploys I prefer to run migrations from within the cloud during application
> start. And it works well for me so far.
>
>
>
> On Wed, Aug 14, 2013 at 5:22 PM, Michael Gentry <mg...@masslight.net>wrote:
>
>> Hi Dmitry,
>>
>> Like Borut, we have many Maven profiles set up to do Flyway migrations
>> in all of our environments and have set up our DBAs with Maven/etc in
>> order for them to do our production migrations. On the Tapestry side,
>> our AppModule has an @Startup method that does a Flyway validate() to
>> ensure the schema is up-to-date or it throws an exception and the
>> application fails to start. We initially thought about having the
>> @Startup do the Flyway migrate(), too, but thought that might be a bit
>> too risky, so we stuck with Maven.
>>
>> mrg
>>
>>
>> On Wed, Aug 14, 2013 at 5:54 AM, Dmitry Gusev <dm...@gmail.com>
>> wrote:
>> > Just curious, and how do you deliver your migrations to target
>> > environments, like production?
>> >
>> > On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <borut.bolcina@gmail.com
>> >wrote:
>> >
>> >> Hello,
>> >>
>> >> no reusable modules at the moment, nor any integration, as we use the
>> >> flyway as a maven plugin. I do see a potential use, but have no clear
>> >> vision on how to use the auto-migration in a more complex
>> >> development/runtime environments. Will have to dedicate some time into
>> it
>> >> and discover safe and clear paths in development cycles in a small
>> >> development team.
>> >>
>> >> There is a live #Tapestry IRC channel, interesting...
>> >>
>> >> Regards,
>> >> borut
>> >>
>> >>
>> >> 2013/8/14 Dmitry Gusev <dm...@gmail.com>
>> >>
>> >> > Hi,
>> >> >
>> >> > It seems Flyway is popular among tapestry users, we've discussed it
>> >> > yesterday on the #tapestry IRC channel.
>> >> >
>> >> > It seems (the only?) advantage of Flyway against Liquibase is that you
>> >> can
>> >> > run custom Java code during migrations.
>> >> >
>> >> > Do you have any reusable modules or, maybe, best practices how you use
>> >> > Flyway with tapestry?
>> >> >
>> >> > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <
>> borut.bolcina@gmail.com
>> >> > >wrote:
>> >> >
>> >> > > Nice Dmitry!
>> >> > >
>> >> > > I (we) use Flyway for database migrations, but it is always nice to
>> >> see a
>> >> > > new Tapestry module!
>> >> > >
>> >> > > Regards,
>> >> > > borut
>> >> > >
>> >> > >
>> >> > > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
>> >> > >
>> >> > > > FYI:
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
>> >> > > >
>> >> > > > --
>> >> > > > Dmitry Gusev
>> >> > > >
>> >> > > > AnjLab Team
>> >> > > > http://anjlab.com
>> >> > > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Dmitry Gusev
>> >> >
>> >> > AnjLab Team
>> >> > http://anjlab.com
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Dmitry Gusev
>> >
>> > AnjLab Team
>> > http://anjlab.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Liquibase for Tapestry5
Posted by Dmitry Gusev <dm...@gmail.com>.
Hi,
I think this is a good point to only check if migrations applied if your
risks are high.
But if something went wrong with migration -- it should be rolled back and
simply won't apply.
So in both cases your application won't be started, whether you stopped
application manually and applied migration from plugin or if you run it
during application start -- isn't it?
It is great if you have direct access to your database, like, via public IP
or VPN.
In this case you can do some migrations even without updating your codebase
and without restarting your app, just using plugins.
I'm also using https://github.com/tlberglund/gradle-liquibase-plugin in
some cases where I have direct database access. But I mostly use it to
generate changesets from database schema so I don't have to write them
manually (I prefer setting <property name="hibernate.hbm2ddl.auto" value=
"update"/> for my development machine so that hibernate updated my db
schema first, so I don't even run liquibase on my development machine --
only on QA, Live environments with few exceptions when it is easier to
quickly write changeset and apply it using the plugin).
The reason I choose to use automatic migrations in my recent projects is
that I use PaaS hosting environments like OpenShift and Jelastic and you
don't always have direct access to database there.
For instance, with OpenShift, deployment is done by simply pushing new code
to git repo. I like that if I put new migrations in commit -- they will be
applied on application rebuild-restart. Of course I can SSH to remote
OpenShift instance and apply migrations manually -- for my projects this is
not productive, because I may doing 3-to-5 redeploys per day and some of
them may include db migrations.
The same with Jelastic, I don't have SSH access to remote instances, but I
may buy public IP to have db access. But for the same reason of often
deploys I prefer to run migrations from within the cloud during application
start. And it works well for me so far.
On Wed, Aug 14, 2013 at 5:22 PM, Michael Gentry <mg...@masslight.net>wrote:
> Hi Dmitry,
>
> Like Borut, we have many Maven profiles set up to do Flyway migrations
> in all of our environments and have set up our DBAs with Maven/etc in
> order for them to do our production migrations. On the Tapestry side,
> our AppModule has an @Startup method that does a Flyway validate() to
> ensure the schema is up-to-date or it throws an exception and the
> application fails to start. We initially thought about having the
> @Startup do the Flyway migrate(), too, but thought that might be a bit
> too risky, so we stuck with Maven.
>
> mrg
>
>
> On Wed, Aug 14, 2013 at 5:54 AM, Dmitry Gusev <dm...@gmail.com>
> wrote:
> > Just curious, and how do you deliver your migrations to target
> > environments, like production?
> >
> > On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <borut.bolcina@gmail.com
> >wrote:
> >
> >> Hello,
> >>
> >> no reusable modules at the moment, nor any integration, as we use the
> >> flyway as a maven plugin. I do see a potential use, but have no clear
> >> vision on how to use the auto-migration in a more complex
> >> development/runtime environments. Will have to dedicate some time into
> it
> >> and discover safe and clear paths in development cycles in a small
> >> development team.
> >>
> >> There is a live #Tapestry IRC channel, interesting...
> >>
> >> Regards,
> >> borut
> >>
> >>
> >> 2013/8/14 Dmitry Gusev <dm...@gmail.com>
> >>
> >> > Hi,
> >> >
> >> > It seems Flyway is popular among tapestry users, we've discussed it
> >> > yesterday on the #tapestry IRC channel.
> >> >
> >> > It seems (the only?) advantage of Flyway against Liquibase is that you
> >> can
> >> > run custom Java code during migrations.
> >> >
> >> > Do you have any reusable modules or, maybe, best practices how you use
> >> > Flyway with tapestry?
> >> >
> >> > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <
> borut.bolcina@gmail.com
> >> > >wrote:
> >> >
> >> > > Nice Dmitry!
> >> > >
> >> > > I (we) use Flyway for database migrations, but it is always nice to
> >> see a
> >> > > new Tapestry module!
> >> > >
> >> > > Regards,
> >> > > borut
> >> > >
> >> > >
> >> > > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
> >> > >
> >> > > > FYI:
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
> >> > > >
> >> > > > --
> >> > > > Dmitry Gusev
> >> > > >
> >> > > > AnjLab Team
> >> > > > http://anjlab.com
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Dmitry Gusev
> >> >
> >> > AnjLab Team
> >> > http://anjlab.com
> >> >
> >>
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Liquibase for Tapestry5
Posted by Michael Gentry <mg...@masslight.net>.
Hi Dmitry,
Like Borut, we have many Maven profiles set up to do Flyway migrations
in all of our environments and have set up our DBAs with Maven/etc in
order for them to do our production migrations. On the Tapestry side,
our AppModule has an @Startup method that does a Flyway validate() to
ensure the schema is up-to-date or it throws an exception and the
application fails to start. We initially thought about having the
@Startup do the Flyway migrate(), too, but thought that might be a bit
too risky, so we stuck with Maven.
mrg
On Wed, Aug 14, 2013 at 5:54 AM, Dmitry Gusev <dm...@gmail.com> wrote:
> Just curious, and how do you deliver your migrations to target
> environments, like production?
>
> On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <bo...@gmail.com>wrote:
>
>> Hello,
>>
>> no reusable modules at the moment, nor any integration, as we use the
>> flyway as a maven plugin. I do see a potential use, but have no clear
>> vision on how to use the auto-migration in a more complex
>> development/runtime environments. Will have to dedicate some time into it
>> and discover safe and clear paths in development cycles in a small
>> development team.
>>
>> There is a live #Tapestry IRC channel, interesting...
>>
>> Regards,
>> borut
>>
>>
>> 2013/8/14 Dmitry Gusev <dm...@gmail.com>
>>
>> > Hi,
>> >
>> > It seems Flyway is popular among tapestry users, we've discussed it
>> > yesterday on the #tapestry IRC channel.
>> >
>> > It seems (the only?) advantage of Flyway against Liquibase is that you
>> can
>> > run custom Java code during migrations.
>> >
>> > Do you have any reusable modules or, maybe, best practices how you use
>> > Flyway with tapestry?
>> >
>> > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <borut.bolcina@gmail.com
>> > >wrote:
>> >
>> > > Nice Dmitry!
>> > >
>> > > I (we) use Flyway for database migrations, but it is always nice to
>> see a
>> > > new Tapestry module!
>> > >
>> > > Regards,
>> > > borut
>> > >
>> > >
>> > > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
>> > >
>> > > > FYI:
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
>> > > >
>> > > > --
>> > > > Dmitry Gusev
>> > > >
>> > > > AnjLab Team
>> > > > http://anjlab.com
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Dmitry Gusev
>> >
>> > AnjLab Team
>> > http://anjlab.com
>> >
>>
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Liquibase for Tapestry5
Posted by Borut Bolčina <bo...@gmail.com>.
Also by running flyway maven plugin with production profile activated. We
have several profiles based on environment and based on database.
What puzzles me at the moment is how to streamline the editorial changes on
some data made after migration has been made. Those changes should be
somehow incorporated into new migration scripts once in a while maybe.
2013/8/14 Dmitry Gusev <dm...@gmail.com>
> Just curious, and how do you deliver your migrations to target
> environments, like production?
>
> On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <borut.bolcina@gmail.com
> >wrote:
>
> > Hello,
> >
> > no reusable modules at the moment, nor any integration, as we use the
> > flyway as a maven plugin. I do see a potential use, but have no clear
> > vision on how to use the auto-migration in a more complex
> > development/runtime environments. Will have to dedicate some time into it
> > and discover safe and clear paths in development cycles in a small
> > development team.
> >
> > There is a live #Tapestry IRC channel, interesting...
> >
> > Regards,
> > borut
> >
> >
> > 2013/8/14 Dmitry Gusev <dm...@gmail.com>
> >
> > > Hi,
> > >
> > > It seems Flyway is popular among tapestry users, we've discussed it
> > > yesterday on the #tapestry IRC channel.
> > >
> > > It seems (the only?) advantage of Flyway against Liquibase is that you
> > can
> > > run custom Java code during migrations.
> > >
> > > Do you have any reusable modules or, maybe, best practices how you use
> > > Flyway with tapestry?
> > >
> > > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <
> borut.bolcina@gmail.com
> > > >wrote:
> > >
> > > > Nice Dmitry!
> > > >
> > > > I (we) use Flyway for database migrations, but it is always nice to
> > see a
> > > > new Tapestry module!
> > > >
> > > > Regards,
> > > > borut
> > > >
> > > >
> > > > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
> > > >
> > > > > FYI:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
> > > > >
> > > > > --
> > > > > Dmitry Gusev
> > > > >
> > > > > AnjLab Team
> > > > > http://anjlab.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Dmitry Gusev
> > >
> > > AnjLab Team
> > > http://anjlab.com
> > >
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Liquibase for Tapestry5
Posted by Dmitry Gusev <dm...@gmail.com>.
Just curious, and how do you deliver your migrations to target
environments, like production?
On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <bo...@gmail.com>wrote:
> Hello,
>
> no reusable modules at the moment, nor any integration, as we use the
> flyway as a maven plugin. I do see a potential use, but have no clear
> vision on how to use the auto-migration in a more complex
> development/runtime environments. Will have to dedicate some time into it
> and discover safe and clear paths in development cycles in a small
> development team.
>
> There is a live #Tapestry IRC channel, interesting...
>
> Regards,
> borut
>
>
> 2013/8/14 Dmitry Gusev <dm...@gmail.com>
>
> > Hi,
> >
> > It seems Flyway is popular among tapestry users, we've discussed it
> > yesterday on the #tapestry IRC channel.
> >
> > It seems (the only?) advantage of Flyway against Liquibase is that you
> can
> > run custom Java code during migrations.
> >
> > Do you have any reusable modules or, maybe, best practices how you use
> > Flyway with tapestry?
> >
> > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <borut.bolcina@gmail.com
> > >wrote:
> >
> > > Nice Dmitry!
> > >
> > > I (we) use Flyway for database migrations, but it is always nice to
> see a
> > > new Tapestry module!
> > >
> > > Regards,
> > > borut
> > >
> > >
> > > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
> > >
> > > > FYI:
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
> > > >
> > > > --
> > > > Dmitry Gusev
> > > >
> > > > AnjLab Team
> > > > http://anjlab.com
> > > >
> > >
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Liquibase for Tapestry5
Posted by Borut Bolčina <bo...@gmail.com>.
Hello,
no reusable modules at the moment, nor any integration, as we use the
flyway as a maven plugin. I do see a potential use, but have no clear
vision on how to use the auto-migration in a more complex
development/runtime environments. Will have to dedicate some time into it
and discover safe and clear paths in development cycles in a small
development team.
There is a live #Tapestry IRC channel, interesting...
Regards,
borut
2013/8/14 Dmitry Gusev <dm...@gmail.com>
> Hi,
>
> It seems Flyway is popular among tapestry users, we've discussed it
> yesterday on the #tapestry IRC channel.
>
> It seems (the only?) advantage of Flyway against Liquibase is that you can
> run custom Java code during migrations.
>
> Do you have any reusable modules or, maybe, best practices how you use
> Flyway with tapestry?
>
> On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <borut.bolcina@gmail.com
> >wrote:
>
> > Nice Dmitry!
> >
> > I (we) use Flyway for database migrations, but it is always nice to see a
> > new Tapestry module!
> >
> > Regards,
> > borut
> >
> >
> > 2013/8/12 Dmitry Gusev <dm...@gmail.com>
> >
> > > FYI:
> > >
> > >
> > >
> >
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
> > >
> > > --
> > > Dmitry Gusev
> > >
> > > AnjLab Team
> > > http://anjlab.com
> > >
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Liquibase for Tapestry5
Posted by Dmitry Gusev <dm...@gmail.com>.
Hi,
It seems Flyway is popular among tapestry users, we've discussed it
yesterday on the #tapestry IRC channel.
It seems (the only?) advantage of Flyway against Liquibase is that you can
run custom Java code during migrations.
Do you have any reusable modules or, maybe, best practices how you use
Flyway with tapestry?
On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina <bo...@gmail.com>wrote:
> Nice Dmitry!
>
> I (we) use Flyway for database migrations, but it is always nice to see a
> new Tapestry module!
>
> Regards,
> borut
>
>
> 2013/8/12 Dmitry Gusev <dm...@gmail.com>
>
> > FYI:
> >
> >
> >
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Liquibase for Tapestry5
Posted by Borut Bolčina <bo...@gmail.com>.
Nice Dmitry!
I (we) use Flyway for database migrations, but it is always nice to see a
new Tapestry module!
Regards,
borut
2013/8/12 Dmitry Gusev <dm...@gmail.com>
> FYI:
>
>
> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>