Meeting Biochemistry Tue 28 Feb

Presents: Anne, Bill, Chris, Rasmus and Wayne

AGENDA

1. New Metamodel draft - Rasmus

2. Review of methods in PIMS API - Chris

It would be good to consider if any are suitable for promotion to the CCPN API.

3. Plans for pilot implementation with Hibernate - Anne/Bill

4. Review of Upgrader code - Bill

This class is designed to be called if the current database version number does not match the current Java classes. It tours the metamodel and updates the database schema where possible. It also has hooks for custom code where scientific logic is needed to make the update.

MEETING

1) Rasmus –\uc CCPN presentation

Data Standard starting from NMR field

CCPN delivers: UML data model, Automatic code generation framework and OO API implementation

Code Generation Framework & Process

OO API: get/set, add/remove, findFirst/findAll, new, delete

Discussion:

• OJB: API for querying –\uc borrow the idea rather than the code

• defect on the delete function + many-to-many relationship inside the db schema

API facilities: only data access, consistency checking, data encapsulation, ApplicationData, Notification (listener) system

Current Status of API:

Stable, released & tested = Python and XML & NMR, Molecule

In testing stage = Java and XML / SQL APIs & Protein Production

CCPN Packages: grouping model, code and data

Model contains: classes with attributes, links and operations, data types, complex data types: classes without links, exceptions

Example NMR data model

Parent-Child tree, rooted in Project:

ensures all objects can be reached from root

All classes have a local key: unchangeable attribute(s), composite, links, or serial. Hibernate business keys. Used for unique string identifier.

Discussion: Why not using serial for everything?

Code Generation upgrade:

Old code generators

New code generation technology

New code generators: core.ModelPortal, core.ModelTraverse (looping over the model), ApiGen

How new system works: ApiGen.writeSetRole –\uc to get the value of an attribute, call

Root package organisation: Old/New

MetaModel: example + description of the new MetaModel

MetaModelElement (for versioning) / ComplexDataType / MetaClass / MetaAttribute & MetaRole

Discussion:

getClassElement(), getSingleClassElement(), getMultipleClassElement()

Complex data type: immutable (value = & clone return self) / mutable

This new data model looks good (Chris)

(CCPN) As we see it...

Access control, Transaction: both should be transparent (if possible)

Transactions:

    Discussion: threadlocal variable = doesn't support recursion better to switch to hibernate for handling caching
    obj.getName(without Transaction for default);
Acces control:

2) Chris –\uc PIMS API
getWritableVersion: you are responsible to call commit or abort
getReableVersion:
findAll:
    Discussion: Project could have a link to version() or subclasses ReadableProject / WritableProject

Access Control:
Exceptions: throws specific exceptions
Generic delete: call specific api delete
findAll() in MemopsBaseClass for generic usage
Collections with lazy loading
get()/set()
Constraints
    for unique constraints should be only in db (Sample.barcode)
    verifyName(value) that returns boolean
    verify(key, value)
    MetaDataType.isValid(value) to covert the data type constraints

3) Anne/Bill –\uc Hibernate
Pilot project: generate Java classes from a test data model, generate the xml mapping file and generate the sql schema.

To do:
Anne: Fixes to SQL schema
Anne: Port SQL generation to new machinery

Anne/Bill: Make time estimate for the below ~ 4mths
Anne: Make small model for testing
Bill: Test cases for implementation of small model
Anne: Verify test cases
Bill: Create Hibernate mapping file
Bill: Create java-hibernate implementation
Anne/Bill: Generate Hibernate mappings and java

Run generator with PP model and run PIMS test cases.
Test performance.
Tune for performance.

4) Bill –\uc Upgrader
Class, attributes & roles
2 stages: create table without roles and then roles
ModelUpdateVersionImpl: DatabaseUpdater() / CCPNMetaUtils (=SqlUtils.py)
Upgrade in place not in new database
Application independent (no call to pims code) but database dependent (for postgresql): it can be done database independent

To do:
Anne: empty db with core tables.
Chris: remove the filter for memops Project
Rasmus: change name of memops.implementation.Project to MemopsRoot.
Putting SQL in metadata?
ccp.model.molecule for the current model: static getPreviousModel() return Molecule 123.class
Versionning problem.

AGREEMENTS Please comment.

- <DONE> ObjectDomain order: Rasmus should send off a collective order within the week. If ObjectDomain will not accept separate payments CCPN should try to pay up front and collect the money.

- <DONE>MetaModel: MetaClass.getClassElements, MetaClass.getSingleElements and MetaClass.getMultipleElements to be added

- Both sides agree that transaction and access control should not be passed as parameters in API functions.

- The ReadableVersion/writableVersion etc. ought to be *identical* to the project, as conceived in the new machinery. NB must check if relevant functions can be fitted in. This should probably be done through a subclass.

- We should add a generic operation for each opType (set, get, add, remove, findFirst, findAll, and new (NB) ) in MemopsBaseClass.

- <NBNB see alternative proposal>The MetaModel should have isValid/verify version for DataTypes. This is to allow value checking in e.g. HTML forms where there are no relevant objects around. There is a java hack that can accomplish this. There will be nothing similar for attributes, roles or classes - any attribute constraints that depend only on value can be recast as new datatypes if
necessary.

- We should do uniqueness checks for local keys as direct SQL statements. Direct checks for global uniqueness (i.e. regardless of parent) would be desirable, but we need to find a way to do it. Direct SQL checks for ad-hoc uniqueness constraints would be nice but is unlikely to happen (any time soon).

- The database upgrader is required within weeks by PIMS. PIMS current system is in Java and compares a new model with the existing database schema. As it is an urgent requirement PIMS will continue it development even if CCPN is likely to things in a rather different manner.

- We should rename 'Project' into 'MemopsRoot'

- As per current plans the CCPN MetaModel will include a GUID for all MetaModelElements. Also, the Model.py model representation will be stored per class rather than per package. This might be used together with CVS/Subversion to provide version numbers for classes.

DISCUSSED, BUT NO FINAL AGREEMENT / ACTION:
- A richer query language for findAll (and findFirst) would be an advantage. The OJB querying API (not their code) might be a good option. Chris to provide further details?

- As regards the new DataObjTypes, mutable structures with value semantics are quite unusual. They will certainly require custom hash functions. CCPN retains the option of going for immutable structures after all, and will keep in contact with the people who put forward the requirement in the first place.
<NBNB - DataObjTypes will be immutable>

- The possibility of collections with lazy loading in database implementation (essentially wrappers around an SQL statement with suitable operations attached) should be kept in mind for future reference, but will not be considered for inclusion in the current round of machinery changes.