migration\i1.0a-release\postgresql\build.xml has a bug

[Alex Yang]

Hi Community,

I found a bug in "migration\i1.0a-release\postgresql\build.xml". 

Since there is no tools/lib, the line "<fileset dir="../../../tools/lib">" will fail. I tried to set to "<fileset dir="../../../db/ddlutils/lib">". It works.

Another question: I have run the ant file build.xml server days again. When there are some new scripts, I have to rerun this ant file. And I noticed that the record in table ad_migrationscript marked as reapplied. What does this mean? Is iDempiere filtered the migration scrips applied and just apply the new ones? Or apply the old scripts once more?

Thanks,

Alex

<taskdef resource="net/sf/antcontrib/antlib.xml">

<classpath>

<fileset dir="../../../db/ddlutils/lib">

<include name="**/*.jar" />

</fileset>

</classpath>

</taskdef>

<taskdef resource="net/sf/antcontrib/antlib.xml">

<classpath>

<fileset dir="../../../tools/lib">

<include name="**/*.jar" />

</fileset>

</classpath>

</taskdef>

[Alex Yang]

I found this in Red1's upgradeassitant.pdf:

Repeat running will not override your

data as the DB has inbuilt constraints against redundant actions.

Next month end you can try running it again and it will give the fresh

latest changes.

Does this also mean that I can rerun the build.xml file in migration\i1.0a-release\postgresql\build.xml?

More, could you let me what enhancement we have done in iDempiere to differentiate this well known problem of ADempiere? :) 

Thanks,

Alex

[Anozi Mada]

Another question: I have run the ant file build.xml server days again. When there are some new scripts, I have to rerun this ant file. And I noticed that the record in table ad_migrationscript marked as reapplied. What does this mean? Is iDempiere filtered the migration scrips applied and just apply the new ones? Or apply the old scripts once more?

 it apply the old scripts again.

Does this also mean that I can rerun the build.xml file in migration\i1.0a-release\postgresql\build.xml?

yes, you can. it's safe as long as you execute the scripts in order, and the ant script help you to do that.

More, could you let me what enhancement we have done in iDempiere to differentiate this well known problem of ADempiere? :)

some new features documented in http://wiki.idempiere.org/en/Category:New_Features_v0.01
but there's a lot more, you can monitor it in iDempiere JIRA

[Alex Yang]

Thanks very much, Anozi.

Does this also mean that I can rerun the build.xml file in migration\i1.0a-release\postgresql\build.xml?

yes, you can. it's safe as long as you execute the scripts in order, and the ant script help you to do that.

How to make sure it? For example, I have a script  "20130301_Insert ad message.sql" to insert a message to AD_Message. I run it in 03/01/2013. Then run this script again in 03/22/2013. Could you let me know how iDempiere handle this to avoid insert the same message to AD_Message? 

Thanks,

Alex

[Anozi Mada]

The insert statement will fail because the same record (identified by it's primary key) has been inserted before.

[Hardmax]

Hi Alex,

A find this on chat meeting (http://www.globalqss.com/wiki/index.php/IDempiere/FullMeeting20121114):

Edwin_Ang: just last week, i started to explore idempiere
Edwin_Ang: i just noticed that there is no ant script to run migration scripts
Edwin_Ang: any replacement script available somewhere?
CarlosRuiz: I don't use that - but I think the build.xml is still there
CarlosRuiz: migration/i1.0a-release/postgresql/build.xml
CarlosRuiz: but I usually run something like:
CarlosRuiz: cd migration
CarlosRuiz: sh migrate_postgresql.sh i1.0a-release commit | psql -U adempiere -d idempiere 2>&1 | tee -a /tmp/i1.0a-release.lst
CarlosRuiz: and at the end I analyze the /tmp/i1.0a-release.lst for errors

In other words, for update here in idempiere we can update database in this way:

  sh migrate_postgresql.sh i1.0a-release commit | psql -U adempiere -d idempiere 2>&1 | tee -a /tmp/i1.0a-release.lst

But I used, some days ago, direct way, and never has problems:

  psql -d idempiere -U adempiere -f PATCH_NUMBER.sql

Where PATCH_NUMBER.sql is the patch what i wish apply. I do this one to one, but I think that the right way is the first, because that script apply after_migrate scripts every time.

Is safe apply all scripts, but is good only apply the last one, after Carlos Change that script a made it smarter and know how patch are apply yet.

Dont forget review if this script and after migration scripts changes.

Regards

[Carlos Antonio Ruiz Gomez]

Hi Alex, Anozi, Max, community

I just published a script that can be helpful for you here:
http://bitbucket.org/CarlosRuiz_globalqss/idempiere-stuff/raw/tip/script_to_sync_db/syncApplied.sh

You must change the initial variables and preferably set .pgpass to avoid psql asking the same password again and again.

This shell:
* check the list of migration scripts on folder vs those applied in database
* apply the scripts that are still not applied
* apply the four post migration scripts
* inform the user to review ERRORS if present on the output files


Although is right that most of the time the scripts will fail safely if you try to apply them again - that could not be true 100% of the time.
Reapplying migration scripts can be ok for a test system - but for a production system is a decision that needs to be carefully weighted.

Hope this scripts helps - I'll appreciate any feedback to improve it.

Regards,

Carlos Ruiz

--

[Sánchez Torres, Max]

Thanks Carlos,

You are amazing... I going to try now.

Regards

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Hardmax]

Hi Carlos, Hi Comunity,

The script work very well, but I notice this message when the script apply the 3rt post migration script:

CREATE FUNCTION

psNEA 1: SELECT nextval('C_1099Box_sq') as currentnext, _sequences.sql:118: ERROR:  relation "c_1099box_sq" does not exist

                        ^

CONSULTA:  SELECT nextval('C_1099Box_sq') as currentnext,

                    currentnextsys

               FROM AD_Sequence WHERE Name = 'C_1099Box' AND istableid = 'Y'

CONTEXTO:  PL/pgSQL function "update_sequences" line 93 at EXECUTE statement

Is it Normal?? I have a problem whit c_1099box_sq or is a problem with the scrip or my database?

The error isn't in a migration script, is in processes_post_migration..

Regards

[Carlos Antonio Ruiz Gomez]

Hi Max, I think that can be related to http://jira.idempiere.com/browse/IDEMPIERE-730 which is in process to be solved.

Regards,

Carlos Ruiz

[Hardmax]

Thanks Carlos,

Regards...

[Dirk Niemeyer]

Hi Carlos,

thanks for the great script!

As I am still on Oracle mainly I can not give you direct feedback but I
created an Oracle version from it which I like to contribute.

Regards,

Dirk Niemeyer

[Carlos Antonio Ruiz Gomez]

Thanks Dirk, uploaded to
https://bitbucket.org/CarlosRuiz_globalqss/idempiere-stuff/src/tip/script_to_sync_db

[redhuan d. oon]

Yes that fix works. I checked out some days ago its already in the latest build.

[Carlos Antonio Ruiz Gomez]

Dirk, I posted changes to your contributed file here:
https://bitbucket.org/CarlosRuiz_globalqss/idempiere-stuff/commits/b167070a5a12613302478dd45ecd87342bba595b

This is because I use it mostly for peer review purposes so I don't want to hide some problems (with the dos2unix and autoadding the initial SETs).

But, for your script I think is worthy to notice that I changed the:
fgrep ERROR

by:
fgrep "ORA-
TNS-
PLS-
SP2-"

Regards,

Carlos Ruiz

[redhuan d. oon]

The Upgrade Assistant is set to its own folder and overriding it will not work. It has to be used as it is. And it will only update you to the date as displayed in the scripts. It is for temporal use for quick preview of iDempiere in Windows environment. At this moment its about 2 months old. If you wish for latest build you have to refer to www.idempiere.org. That will need some more effort but its worth it.