cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Soheil Eizadi <seiz...@infoblox.com>
Subject RE: Database Access
Date Tue, 07 May 2013 05:00:51 GMT
Hi Vijay,
Thanks for detail on the Database access. If you are OK with it, when I have time I will create
a page for this in the Wiki and copy this information there.
-Soheil
________________________________________
From: Vijayendra Bhamidipati [vijayendra.bhamidipati@citrix.com]
Sent: Monday, May 06, 2013 7:02 PM
To: dev@cloudstack.apache.org
Subject: RE: Database Access

Hi Soheil,

Cloudstack internally uses cglib and ehcache to create and cache POJO (plain old java object)
proxy objects in the db schema. The DAO layer has been written such that most routines that
you will ever need to work with the POJOs, read a record from the db, or a list of records
from the db, write a record to the db, find a record or a list of records by id in a table
using conditions, and so on, have been implemented in GenericDaoBase.java.

Say you want to create a new table in the cloud schema, mytable. You first edit the appropriate
sql script (which would be setup/db/db/schema410to420.sql if you're working on the current
master) to include a create table my_table_name_in_cloud_schema DDL there. When you run `
mvn -e -P developer -pl developer -Ddeploydb;`, this table will get created in the cloud schema,
and you can check that by logging into the mysql db. Next, you need a POJO to be able to hold
a record of this table, in the cloudstack mgmt. server - so you define a new class for this.
This class is called a "View Object" or VO. You call your class "mytableVO", typically like
this:

@Entity
@Table(name="my_table_name_in_cloud_schema")
public class mytableVO implements mytable {


  @Column(name="column_name_in_cloud_schema_table")
  private <type> <a_field_name>; // Your field name here needn't match the actual
column name in your table on mysql.

  @Column<repeat the above>
.
.
   // Next, getter and setter methods for each field.

  // Two constructors, one taking in as arguments the minimum number of fields you want when
creating this VO.
  // The other, a default constructor that typically generates a uuid for the uuid field.
}

So next, how do you fill up this VO with the corresponding columns of a record from the db?
You need to tie this VO to a Dao class - one that extends the GenericDaoBase class. So you
typically create an interface, mytableDao extends GenericDao<mytableVO, ...>. In this
interface, you put in functions that you need specially for your own Dao implementation -
say you want to run a complicated query where you create your own views and query from that,
or use multiple conditions etc - you put a function declaration there called mytables_complicatedfunc()
in there.

Next, you'll create a class to implement the above interface. Call it mytableDaoImpl. It will
extend mytableDao. In here, you will implement your complicated function using Search Builders.
In a search builder, you can multiple conditionals - basically the where part of a sql query.
Here's an example:

        vmIdSearch = createSearchBuilder();
        vmIdSearch.and("vmId", vmIdSearch.entity().getCloneType(), Op.EQ);
        vmIdSearch.done();

What you're doing here is that you're using the field name in the POJO you created (mytableVO)
(here it is "vmId"). You're saying, get the clone type from the db, and check if it's equal
(Op.EQ) to the vmId that you will supply to it. How do you supply the vmId? You instantiate
the search builder you created above, then use that instance.setParameters("vmId", pass_your_vm_id_here).
Then you pass this instance to one of GenericDaoBase's functions.

You typically will have an id/uuid column in your table, where they need to be autogenerated.
You must use the @GeneratedValue annotation when you want to do that. Check out one of the
Dao classes - a very simple one is one that I put in for the full clones feature a few weeks
ago, and from which comes the excerpt that I used above.

When you implement a new table thus, you should also leverage the mockito frameworks already
provided by cloudstack - to write a simple unit test to check if the table works as expected,
you can refer to the commit cd291f6b4b5b851595ef11c5f14def9afddb6a1a on the master. Should
make things easier :)

Finally, you will never see the actual proxy objects themselves - they're always hidden by
cglib. Typically, you shouldn't need to know about them.


Cheers!
Regards,
Vijay

-----Original Message-----
From: Soheil Eizadi [mailto:seizadi@infoblox.com]
Sent: Monday, May 06, 2013 5:01 PM
To: dev@cloudstack.apache.org
Subject: Database Access

I am trying to understand the details of DAO model in order implement it for our Network Element.

There is a reference to documentation "See Database Access for more details." But no link
:( https://cwiki.apache.org/CLOUDSTACK/putting-cloudstack-together.html

I searched the wiki for detailed information about the Database Access, found some references
about the refractoring work, but nothing related to my use case.

I find some information on SlideShare: http://www.slideshare.net/cloudstack/management-server-internals
For the "Example DAO", slides 13-14, were useful.

If there is a pointer to more detailed information that would be great.
Thanks,
-Soheil

Mime
View raw message