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.bhamidip...@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:seiz...@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
