Difference between revisions of "Metas best practices / bugfixes / improvements"

Latest revision as of 13:39, 17 September 2013

Status

• JIRA: https://adempiere.atlassian.net/browse/ADEMPIERE-195
• Mercurial branch: https://hg.code.sf.net/p/adempiere/code branch ADEMPIERE-195

Contributors

Metas

Overview

EntityType Field

• length is now 255

IQueryBL

• decouple queries from actual JDBC database
• added t_query_selection, needed by Query guaranteed iterator

org.adempiere.ad.migration

Refactored, fixed and improved XML migration:

• module refactored to be service-oriented
• stabilization: major improvement of transaction management and error propagation
• extraction (when generating steps) of application dictionary objects that have a different entity type from the one sought for
• migrations with missing AD objects (such as columns, tables etc) will be applied and the troublesome objects will be skipped if possible, or suitable errors will be thrown
• execution of migration scripts with constraints deferred
• separation of DML and DDL operations in BL

TrxBL

• introduced ITrxListener which is called after a transaction was commited

org.adempiere.ad.wrapper

• introduced POJOWrapper which wrapps a generated interface to a decoupled java.util.Map; used for decoupled junit testing
• GridTabWrapper - fixes on old GridTabWrapper
• POWrapper - fixes on old POWrapper
• InterfaceWrapperHelper - facade which decides which wrapper to be used (POWrapper, GridTabWrapper, POJOWrapper) based on given model. From now on, only this wrapper shall be directly used by user code

ISysConfigBL, ISysConfigDAO

• services used to query AD_SysConfig variables

MsgBL

• service used to query AD_Message

org.adempiere.util

• org.adempiere.util.collections - helpers for collections processing (iterator implementations)
• org.adempiere.util.comparator - comparator implementations
• org.adempiere.util.concurrent - thread pool, future, thread factory implementations in order to help synchronization of threads

SystemTime, TimeSource

• helpers to offer a universal timesource for the entire application

org.adempiere.util.trxConstraints

Transaction constraints can be defined on a per-thread basis and are enforced by the system. A user can obtain her constraints instance by calling org.compiere.util.DB.getConstraints() and can then customize that instance for the particular thread's needs. 

Motivation: 

Within ADempiere, we should have a way to enforce trx-Constraints to guard against misbehaving code which might otherwise affect the overall runtime stability of the system.

Examples: 

When implementing a new process, we want to make sure that there is no unexpected stuff taking place outside of the "main" transaction (e.g. in custom model validators). 
When working on complex issues (e.g. GUIs with a lot of callouts), we want to make sure that no open transactions are left behind to block further database access 
Therefore we need to specify (e.g.) that there may only be a limited number of transactions opened from the current thread at the same time. Or a limited number of save points per transaction. Or, that all transactions opened by a given thread have to be finished (committed or rolled back) within a given timeout.

ModelClassGenerator, ModelInterfaceGenerator

• generate model getters/setters
• referenced models are locally cached in parent PO

org.adempiere.ad.modelvalidator

API for implementing and controlling the lifecycle of a model validator.

At this moment, the package contains only the API related to annotated model validators.
An annotated model validator can be any class which respects following format and is annotated properly.
e.g.
<code>
@Validator(I_C_Order.class)
public class C_Order
{
	@DocValidate(timings = { ModelValidator.TIMING_BEFORE_PREPARE })
 public void doSomethingBeforePrepare(org.compiere.model.I_C_Order order)
 {
 ....
 }
 
 @ModelChange(timings = ModelValidator.TYPE_BEFORE_DELETE)
 public void doSomethingBeforeDelete(org.compiere.model.I_C_Order order)
 {
 ....
 }
}
</code>

To register this model validator, all you need to do is:
<code>
{@link org.compiere.model.ModelValidationEngine}.get().addModelValidator(new C_Order());
</code>
Internally, addModelValidator method will call check if the given object is an annotated model validator and if yes, it will use {@link org.adempiere.ad.modelvalidator.AnnotatedModelValidatorFactory#createModelValidator(Object)} to wrap it and create an {@link org.compiere.model.ModelValidator} implementation.

For more infos, please check annotations from org.adempiere.ad.modelvalidator.annotation package.

Please note that the old way of defining and using model validators is still fully supported.

@task http://dewiki908/mediawiki/index.php/Me00_02505:_Uncouple_Annotated_ModelValidators_from_API_implementations_%282012022410000053%29

@see org.adempiere.ad.modelvalidator.annotations.Validator
@see org.adempiere.ad.modelvalidator.annotations.ModelChange
@see org.adempiere.ad.modelvalidator.annotations.ModelChanges
@see org.adempiere.ad.modelvalidator.annotations.DocValidate
@see org.adempiere.ad.modelvalidator.annotations.DocValidates

Table & Columns improvements

• introduced Lazy loaded columns. i.e. if a column is flagged as Lazy then it won't be loaded when the PO object is loaded, but just when getValue is called
• introduced AD_Column.IsCalculated: calculated columns will be excluded when we are copying from one PO to another

Purpose

References

Design Considerations

Assumptions

Dependencies

Constraints

Glossary

Functional Requirements

Functional team

• Volunteers for analyzing:
• Result of analysis:

User roles & profiles

Business process definition

User stories

Functional requirements based on business processes

User Interface Mockups

Acceptance criteria

QA and test cases

Development infrastructure

Technical Requirements

Technical team

• Volunteers for analyzing:
• Result of analysis:

Data Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items