Reverted because developer doesn't have permissions to commit on trunk - please next time upload a patch for peer review.
_________________
Peer reviewed -> script 340s-351a/postgresql/047_libero_migration_script.sql changed the size of M_Product.Name from 60 (standard for all adempiere name columns) to 255.
Pending to check consistency and best approach to solve with functional pmc group.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reverted because developer doesn't have permissions to commit on trunk - please next time upload a patch for peer review.
_________________
Peer reviewed -> script 340s-351a/postgresql/047_libero_migration_script.sql changed the size of M_Product.Name from 60 (standard for all adempiere name columns) to 255.
Pending to check consistency and best approach to solve with functional pmc group.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What needs reviewing here ? This is clearly a bug. Why would you not want to commit this? When people like me do implementations - and we find silly little things like this - they should be fixed. The overhead of loading a patch, getting peer review (and let's not forget that the VAT return has not been added because no one has reviewed it even though all Europeans need it) - so why do we want to make it so difficult to improve ADempiere?
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The commit in rev:1392 also had technical problems. http://adempiere.svn.sourceforge.net/adempiere/?rev=13923&view=rev
The postgresql script would not have worked, as provided. There is no NVARCHAR2 data type and no ALTER TABLE table MODIFY statement in Postgresql. In both scripts the UPDATED and UPDATEDBY were not updated.
It would have been safer to set the "Log migration script" in preferences, do the changes in the dictionary and use the generated scripts.
Regards,
Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right Tony, thanks for the additional peer review. Just found also that changing the help in AD_Column is useless as it will be overwritten by synchronize terminology process.
As I see there are 67 name columns with size different than 60 (and 340 standardized):
[
select tablename, columnname, fieldlength
from ad_column c join ad_table t on (t.ad_table_id=c.ad_table_id) where ad_element_id=469
and fieldlength!=60
order by 1,2
]
Perhaps a better solution is to change the element help to avoid the mention of the "60" length.
___________
@MJudd, the reason of the revert is because you don't have permissions at this moment until some technical and community issues are agreed within community. You need to upload patches for peer review instead of committing directly.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mike said it best. Review is not solving those silly things that we implementers have found. This brings more overhead. By saying that, "Review" sounds like a dirty word. I remember the days of JazzERP and wonder if this is what Mike meant of an ideal project. There was no public review and no one around to review it or else i would have joined it.
Btw Carlos, can you please review your ban of Trifon. His commit was less an issue than Mike's here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fair points tony. I rarely get the guts to actually contribute anything these days as there is always such a 'fight' that I experience. I guess all the things you learn - you forget when - when you are discouraged from regular contribution.
I personally don't accept the the 'ban' imposed illegally - it is a common view in the west that illegal actions and illegal rule should not be acknowledged as legitimate. This extends to where legitimate appointments have abused their position. So I think it would be better to focus on the facts and not to muddy the waters in this tracker with herring issues.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@MJudd, the PMC Head Concept established the empowerment to ban disruptive developers from trunk, and it established also the procedure to follow if you consider this illegal and/or abusive.
As I'm following a procedure established and empowered by community I invite you to do the same. Following the established procedure will avoid the flame you're trying to raise here alleging illegality and abuse without providing facts.
Cordially,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fixed in rev r1392
Reverted because developer doesn't have permissions to commit on trunk - please next time upload a patch for peer review.
_________________
Peer reviewed -> script 340s-351a/postgresql/047_libero_migration_script.sql changed the size of M_Product.Name from 60 (standard for all adempiere name columns) to 255.
Pending to check consistency and best approach to solve with functional pmc group.
Regards,
Carlos Ruiz
Reverted because developer doesn't have permissions to commit on trunk - please next time upload a patch for peer review.
_________________
Peer reviewed -> script 340s-351a/postgresql/047_libero_migration_script.sql changed the size of M_Product.Name from 60 (standard for all adempiere name columns) to 255.
Pending to check consistency and best approach to solve with functional pmc group.
Regards,
Carlos Ruiz
What needs reviewing here ? This is clearly a bug. Why would you not want to commit this? When people like me do implementations - and we find silly little things like this - they should be fixed. The overhead of loading a patch, getting peer review (and let's not forget that the VAT return has not been added because no one has reviewed it even though all Europeans need it) - so why do we want to make it so difficult to improve ADempiere?
Mike
The commit in rev:1392 also had technical problems.
http://adempiere.svn.sourceforge.net/adempiere/?rev=13923&view=rev
The postgresql script would not have worked, as provided. There is no NVARCHAR2 data type and no ALTER TABLE table MODIFY statement in Postgresql. In both scripts the UPDATED and UPDATEDBY were not updated.
It would have been safer to set the "Log migration script" in preferences, do the changes in the dictionary and use the generated scripts.
Regards,
Tony
You're right Tony, thanks for the additional peer review. Just found also that changing the help in AD_Column is useless as it will be overwritten by synchronize terminology process.
As I see there are 67 name columns with size different than 60 (and 340 standardized):
[
select tablename, columnname, fieldlength
from ad_column c join ad_table t on (t.ad_table_id=c.ad_table_id) where ad_element_id=469
and fieldlength!=60
order by 1,2
]
Perhaps a better solution is to change the element help to avoid the mention of the "60" length.
___________
@MJudd, the reason of the revert is because you don't have permissions at this moment until some technical and community issues are agreed within community. You need to upload patches for peer review instead of committing directly.
Regards,
Carlos Ruiz
Mike said it best. Review is not solving those silly things that we implementers have found. This brings more overhead. By saying that, "Review" sounds like a dirty word. I remember the days of JazzERP and wonder if this is what Mike meant of an ideal project. There was no public review and no one around to review it or else i would have joined it.
Btw Carlos, can you please review your ban of Trifon. His commit was less an issue than Mike's here.
@Redhuan,
https://sourceforge.net/projects/adempiere/forums/forum/611167/topic/3751471?message=8481791
Regards,
Carlos Ruiz
Fair points tony. I rarely get the guts to actually contribute anything these days as there is always such a 'fight' that I experience. I guess all the things you learn - you forget when - when you are discouraged from regular contribution.
I personally don't accept the the 'ban' imposed illegally - it is a common view in the west that illegal actions and illegal rule should not be acknowledged as legitimate. This extends to where legitimate appointments have abused their position. So I think it would be better to focus on the facts and not to muddy the waters in this tracker with herring issues.
Mike
@MJudd, the PMC Head Concept established the empowerment to ban disruptive developers from trunk, and it established also the procedure to follow if you consider this illegal and/or abusive.
As I'm following a procedure established and empowered by community I invite you to do the same. Following the established procedure will avoid the flame you're trying to raise here alleging illegality and abuse without providing facts.
Cordially,
Carlos Ruiz
Proper script contributed here:
http://adempiere.hg.sourceforge.net/hgweb/adempiere/adempiere361/rev/3073f5ca759d
Fixing the mismatch in I_Product, but also in M_Product_Trl
_________________
Carlos Ruiz