You can subscribe to this list here.
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|
From: Derrick S. <der...@gm...> - 2010-09-16 17:32:38
|
So I seem to have "fixed" it by making it a Spring bean rather than a context listener. Not quite sure why this would be problematic -- I'd rather have autopatch isolated even though, truthfully, I'm not going to stop using Spring -- but at least it's now running the patches. The errors it's reporting now are the ones I'd expect: table exists, yada yada yada. But I wanted to get to that point first, and I'll just bump the patch number manually. Derrick On Wed, Sep 15, 2010 at 9:52 PM, Alex Soto <ap...@gm...> wrote: > It's been a while for me, but I've definitely been bit by it before. As > Mike says, your classpath probably has the same dir/war/jar twice. > > On Sep 15, 2010, at 7:57 PM, Mike Hardy wrote: > > > Hello there - > > This is a problem that others have reported before, and it is usually the > case that the patches only exist in one spot, but they are somehow included > in the classpath twice - usually the logging includes the classpath that was > seen, and that can be used to determine that they are actually referenced a > couple times for some reason. > > That's a bit vague (I apologize), but perhaps if you posted the debugging > log it'd be easy for me (or someone else) to see from the output if that is > the case? > > Sometimes when I'm having troubles like this it's helpful for me just to > hear that it is working and possible, so I will say that I have definitely > had this reported from others, and even seen it myself when I wasn't doing > things right for whatever reason, but patch discovery *does* work, and there > must be a reason and a solution for this. Likely small and easy even, once > the real trouble source is found. > > Hopefully the log'll be the thing that makes it clear > > -Mike > > On Sep 15, 2010, at 10:17 PM, Derrick Schneider wrote: > > Hi, I'm just getting started with autopatch, integrating it into an > existing environment. > > I've renamed my existing SQL scripts to fit the autopatch naming convention > (patchNNNN_text.sql) and configured autopatch to find them in the classpath > (I'm running the web application version). The problem is that it's finding > each patch twice, and of course complaining that multiple patches have the > same number. I have 18 existing SQL patches, and autopatch tells me it finds > 36. > > I've looked in the war that's being deployed with the patches, and there's > only one copy of each file. I assume later patches will fail legitimately as > things like create tables fail on the existing schema, but the first patch > is just a no-op sql script. > > My migration.properties lists this: > appdb.patch.path=patches.appdb > > And my patches/appdb directory has files such as > patch0001_no_op.sql > ... > patch0018_user_table_last_login.sql > > I cranked up autopatch's logging level, and sure enough, it says "found 36 > patches" and then proceeds to log about each one from the same directory. > > This is with autopatch 1.0.2, but it also failed on 1.2-b (I went to the > earlier version thinking it might be a bug). > > Thanks for your help > Derrick > > -- > Writer. Programmer. Puzzle Designer. > http://www.obsessionwithfood.com > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > autopatch-users mailing list > aut...@li... > https://lists.sourceforge.net/lists/listinfo/autopatch-users > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > autopatch-users mailing list > aut...@li... > https://lists.sourceforge.net/lists/listinfo/autopatch-users > > > -- Writer. Programmer. Puzzle Designer. http://www.obsessionwithfood.com |
|
From: Alex S. <ap...@gm...> - 2010-09-16 04:52:36
|
It's been a while for me, but I've definitely been bit by it before. As Mike says, your classpath probably has the same dir/war/jar twice. On Sep 15, 2010, at 7:57 PM, Mike Hardy wrote: > > Hello there - > > This is a problem that others have reported before, and it is usually the case that the patches only exist in one spot, but they are somehow included in the classpath twice - usually the logging includes the classpath that was seen, and that can be used to determine that they are actually referenced a couple times for some reason. > > That's a bit vague (I apologize), but perhaps if you posted the debugging log it'd be easy for me (or someone else) to see from the output if that is the case? > > Sometimes when I'm having troubles like this it's helpful for me just to hear that it is working and possible, so I will say that I have definitely had this reported from others, and even seen it myself when I wasn't doing things right for whatever reason, but patch discovery *does* work, and there must be a reason and a solution for this. Likely small and easy even, once the real trouble source is found. > > Hopefully the log'll be the thing that makes it clear > > -Mike > > On Sep 15, 2010, at 10:17 PM, Derrick Schneider wrote: > >> Hi, I'm just getting started with autopatch, integrating it into an existing environment. >> >> I've renamed my existing SQL scripts to fit the autopatch naming convention (patchNNNN_text.sql) and configured autopatch to find them in the classpath (I'm running the web application version). The problem is that it's finding each patch twice, and of course complaining that multiple patches have the same number. I have 18 existing SQL patches, and autopatch tells me it finds 36. >> >> I've looked in the war that's being deployed with the patches, and there's only one copy of each file. I assume later patches will fail legitimately as things like create tables fail on the existing schema, but the first patch is just a no-op sql script. >> >> My migration.properties lists this: >> appdb.patch.path=patches.appdb >> >> And my patches/appdb directory has files such as >> patch0001_no_op.sql >> ... >> patch0018_user_table_last_login.sql >> >> I cranked up autopatch's logging level, and sure enough, it says "found 36 patches" and then proceeds to log about each one from the same directory. >> >> This is with autopatch 1.0.2, but it also failed on 1.2-b (I went to the earlier version thinking it might be a bug). >> >> Thanks for your help >> Derrick >> >> -- >> Writer. Programmer. Puzzle Designer. >> http://www.obsessionwithfood.com >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ >> autopatch-users mailing list >> aut...@li... >> https://lists.sourceforge.net/lists/listinfo/autopatch-users > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > autopatch-users mailing list > aut...@li... > https://lists.sourceforge.net/lists/listinfo/autopatch-users |
|
From: Mike H. <mi...@mi...> - 2010-09-16 03:20:05
|
Hello there - This is a problem that others have reported before, and it is usually the case that the patches only exist in one spot, but they are somehow included in the classpath twice - usually the logging includes the classpath that was seen, and that can be used to determine that they are actually referenced a couple times for some reason. That's a bit vague (I apologize), but perhaps if you posted the debugging log it'd be easy for me (or someone else) to see from the output if that is the case? Sometimes when I'm having troubles like this it's helpful for me just to hear that it is working and possible, so I will say that I have definitely had this reported from others, and even seen it myself when I wasn't doing things right for whatever reason, but patch discovery *does* work, and there must be a reason and a solution for this. Likely small and easy even, once the real trouble source is found. Hopefully the log'll be the thing that makes it clear -Mike On Sep 15, 2010, at 10:17 PM, Derrick Schneider wrote: > Hi, I'm just getting started with autopatch, integrating it into an existing environment. > > I've renamed my existing SQL scripts to fit the autopatch naming convention (patchNNNN_text.sql) and configured autopatch to find them in the classpath (I'm running the web application version). The problem is that it's finding each patch twice, and of course complaining that multiple patches have the same number. I have 18 existing SQL patches, and autopatch tells me it finds 36. > > I've looked in the war that's being deployed with the patches, and there's only one copy of each file. I assume later patches will fail legitimately as things like create tables fail on the existing schema, but the first patch is just a no-op sql script. > > My migration.properties lists this: > appdb.patch.path=patches.appdb > > And my patches/appdb directory has files such as > patch0001_no_op.sql > ... > patch0018_user_table_last_login.sql > > I cranked up autopatch's logging level, and sure enough, it says "found 36 patches" and then proceeds to log about each one from the same directory. > > This is with autopatch 1.0.2, but it also failed on 1.2-b (I went to the earlier version thinking it might be a bug). > > Thanks for your help > Derrick > > -- > Writer. Programmer. Puzzle Designer. > http://www.obsessionwithfood.com > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > autopatch-users mailing list > aut...@li... > https://lists.sourceforge.net/lists/listinfo/autopatch-users |
|
From: Derrick S. <der...@gm...> - 2010-09-16 02:17:50
|
Hi, I'm just getting started with autopatch, integrating it into an existing environment. I've renamed my existing SQL scripts to fit the autopatch naming convention (patchNNNN_text.sql) and configured autopatch to find them in the classpath (I'm running the web application version). The problem is that it's finding each patch twice, and of course complaining that multiple patches have the same number. I have 18 existing SQL patches, and autopatch tells me it finds 36. I've looked in the war that's being deployed with the patches, and there's only one copy of each file. I assume later patches will fail legitimately as things like create tables fail on the existing schema, but the first patch is just a no-op sql script. My migration.properties lists this: appdb.patch.path=patches.appdb And my patches/appdb directory has files such as patch0001_no_op.sql ... patch0018_user_table_last_login.sql I cranked up autopatch's logging level, and sure enough, it says "found 36 patches" and then proceeds to log about each one from the same directory. This is with autopatch 1.0.2, but it also failed on 1.2-b (I went to the earlier version thinking it might be a bug). Thanks for your help Derrick -- Writer. Programmer. Puzzle Designer. http://www.obsessionwithfood.com |
|
From: Alex S. <ap...@gm...> - 2008-01-24 18:34:48
|
Hi Natalia, That's pretty much it in my opinion. I haven't done anything fancier than that. (a) is usually for dev environments (b) is required when the patch has already gone into an environment where you can't do (a) Alex On Jan 24, 2008, at 10:11 AM, Natalia Usmanova wrote: > Hi! > I have hopefully a simple question. What are my options for rolling > back N last patches applied to a database using Autopatch? > I can only think of the following: > a) assuming i have patches that allow me to rebuild the database > from scratch, delete the database and rebuild it to the patch level > (Current Patch Level - N) > or > b) create a new patch that would essentially cancel the last N > patches (not a true roll back though) > > Any other options? > > Thank you much, > Natalia. > > Never miss a thing. Make Yahoo your homepage. > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > autopatch-users mailing list > aut...@li... > https://lists.sourceforge.net/lists/listinfo/autopatch-users |
|
From: Natalia U. <nat...@ya...> - 2008-01-24 18:11:06
|
Hi!
I have hopefully a simple question. What are my options for rolling back N last patches applied to a database using Autopatch?
I can only think of the following:
a) assuming i have patches that allow me to rebuild the database from scratch, delete the database and rebuild it to the patch level (Current Patch Level - N)
or
b) create a new patch that would essentially cancel the last N patches (not a true roll back though)
Any other options?
Thank you much,
Natalia.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs |