Home > ReleaseNotes

4.4.0

Release Date : April 14, 2008

Backward compatibility

  • Method Adaptation.getValidationReport(): this method henceforth checks that the instance is activated, so as to ensure by default that mandatory elements (minOccurs="1") are all present. The previous behaviour of this method was less restrictive and was consequently error-prone because it could tell that there was no errors but indeed some mandatory elements were not present.
  • Method Adaptation.checkActivable(): this method has been deprecated, because its name is confusing. It has indeed the same result as Adaptation.getValidationReport() above.
  • Method Adaptation.isSchemaDefinitionCompliant(boolean): The boolean parameter's meaning has changed, it henceforth checks whether the instance is activated (warnings are no more taken into account for the result).
  • Due to the enhancement on lock management the locks on homes are not migrated. When upgrading to this new version, all branches should be unlocked.

Forward compatibility

  • Due to new view sharing feature, a repository from this version cannot be reused with an older version. Before upgrading to this new version, please backup your repository (database).

Bug Fixes

  • [01678] Table content does not support a read concurrent access when an archive's import is made.
  • [01686] Optimize and Refactor - Mutualize common values procedure does nothing on tables without non-key columns.
  • [01688] Count operation should return an integer but WSDL declares a string type.
  • [01689] Validation operation may return empty validationReport but WSDL does not define a minOccurs=0
  • [01690] On an adaptation under an agreement, the distributor has a read-only access to tables, if he participates in a read-only role, even if there is no restriction defined.
  • [01691] Service permission rules on table occurrence are checked upon any table even not targeted by the service definition.
  • [01695] The domain name is limited to 3 characters for the 'email' type. It should be unlimited (ex:.localdomain, .info, ..).
  • [01696] Triggers handleBeforeModify and handleAfterModify are not executed if a mass-update is performed.
  • [01697] The methode ProcedureContext.doMergeToParent does not consider the allPriviledges property set.
  • [01698] EBX.Manager user session is lost (timeout) during long process (archive import-export, branch & version validation, ...).

Performance: incremental validation

Internal validation framework has been thoroughly reviewed so as to work incrementally. This means that if some data updates occur, only the potentially impacted parts will be revalidated. When an adaptation instance has been validated at least once, the validation time is extremely reduced, even on large repositories.

If application server is restarted, a full validation is still required, hence the validation time is not reduced for this scenario.

More recommendations for optimizing validation times is available in the new chapter Performance Guidelines.

Lock Management

The branch's lock management has been rewritten:

  • It is now possible to have long process locking a branch without seeing the branch unlocked by a merge process.
  • User description of lock has been internationalized.
  • API has been moved to a dedicated Java class, LockSpec.

Repository purge

Unused or obsolete homes can be physically deleted from the repository. This happens in two steps:

  1. mark the home intended to be purged,
  2. trigger the purge.

Purge process

  • Once a home has been marked for purge, it cannot be reopened, and its content becomes unavailable.
  • Physical purge happens only after step 2.
  • Physically deleting a home also deletes its index files on disk.

EBX.Manager

EBX.Manager provides administrator profile a GUI for marking and purging a home at the same time.

Performance

  • An optional modification of database schema is included in ddl.sql: adding the provided index on table EBX_HTB will speed up the purge process:
     
    create index EBX_BIX on EBX_HTB (table_rid, bloc_id, revision_id);

API

See Repository.markHomeForPurge(AdaptationHome, Session).
See Repository.purgeHomes(Session).

Dataservices

A new operation is available on DataServices, it is now possible to validate directly an instance.

Shared views

Views can now be shared across several users.

  • View owner is now a profile (a user or a role).
  • Other profiles (users or roles) can be allowed to use a view defined by the owner.

Access permission resolution on nodes

Resolution procedure for access permission on nodes has been reviewed, especially for table nodes and table child nodes.

A table node child resolved access permission is then computed as follows:

  • access right defined on table child node is its specific access right if defined, or its table node specific access right if defined, or the default access right for instance's values;
  • at node level, access right resolved on table child node is:
    • the minimum of access rights defined for this table child node on all restricted profiles of the target user;
    • or the maximum of access rights defined for this table child node on all profiles of the target user, if no restriction is defined;
  • the final resolved access right is always the minimum between resolved access rights of: branch, instance, table node child and programmatic rules.

Consequently, at node level, a table node resolved access permission is always equal to the maximum of the resolved access right of its children. Its final resolved access right is the minimum between resolved access rights of: branch, instance, table node child and programmatic rules.

For more information, see also Resolution of permissions.

Documentation

A "Performance Guidelines" chapter has been added to the documentation.

 

Home > ReleaseNotes