Hi Soheil, Sure! :)
Cheers! Regards, Vijay ________________________________________ From: Soheil Eizadi [seiz...@infoblox.com] Sent: Monday, May 06, 2013 10:00 PM To: dev@cloudstack.apache.org Subject: RE: Database Access 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