> 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 developer. --Alex
