cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: Hibernate
Date Tue, 03 Jul 2012 07:02:12 GMT
> I don't want to speak for Alex, but I have heard him mention such a change
> number of times, and have seen it in his slides as well.
> But the larger sense is that if we are going to change something in AWSAPI
> for communicating to the database, it should be something that we are
> comfortable with adopting in the long term for the rest of CloudStack,
> otherwise we'll end up with two different ways for connecting to the
> database, which is fail.

For the longer term of ORM layer for CloudStack, I think we should look at it as follows.

- CloudStack's contract to the DB are in the VO objects and the JPA annotations.
- JPA should continue to be CloudStack's meta language for the DB schema.  There is good support
on eclipse for JPA and is well known enough now.
- CloudStack Orchestration Layer will probably not deviate from the current DAO implementations.
 CloudStack Orchestration Layer needs direct access to DB for locking and ensuring atomicity
and the current framework has been efficient in providing that and has been bug free for a
long time.  In my experience, other frameworks provide too much functionality and too easy
to bring about mistakes.
- However, the majority of DB access is not in CloudStack Orchestration Layer.  It is in the
CloudStack REST API and business logic.  For those, we will be refactoring and we need to
decide on an a search framework to use.  Currently, it uses the same DAO layer that CloudStack
Orchestration Layer uses and that's incorrect.  The custom DAO layer was never meant to be
used as a generic search framework.  This effort involves building indexes (perhaps lucene)
and work in terms of response objects that are often multiple joins of tables.  We should
start a discussion on that on a different thread.
- When CloudStack calls plugins, the transaction it uses terminates.  All objects sent to
and returned by plugins should be sanitized by interfaces or pure pojos.  Plugins need to
ensure their own operations are idempotent and does not rely on transactions started by CloudStack
to roll back states.  Therefore, plugins are free to pick their own ORM.  CloudStack will
provide a recommendation on the ORM implementation to use but it's up to the choice of the


View raw message