Yeah, I've saved off this e-mail, but it would be great to have it on the
Wiki. :)
On Tue, May 7, 2013 at 9:17 AM, Vijayendra Bhamidipati <
vijayendra.bhamidip...@citrix.com> wrote:
> 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
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
