You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Soheil Eizadi <se...@infoblox.com> on 2013/05/07 02:00:35 UTC
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
Re: Database Access
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.bhamidipati@citrix.com> wrote:
> Hi Soheil,
>
> Sure! :)
>
> Cheers!
> Regards,
> Vijay
> ________________________________________
> From: Soheil Eizadi [seizadi@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.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
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
RE: Database Access
Posted by Vijayendra Bhamidipati <vi...@citrix.com>.
Hi Soheil,
Sure! :)
Cheers!
Regards,
Vijay
________________________________________
From: Soheil Eizadi [seizadi@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.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
RE: Database Access
Posted by Soheil Eizadi <se...@infoblox.com>.
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
RE: Database Access
Posted by Vijayendra Bhamidipati <vi...@citrix.com>.
Also, you will need to follow the coding guidelines for cloudstack when naming the db columns (refer to the Database Conventions section) :
https://cwiki.apache.org/CLOUDSTACK/coding-conventions.html
Regards,
Vijay
-----Original Message-----
From: Vijayendra Bhamidipati [mailto:vijayendra.bhamidipati@citrix.com]
Sent: Monday, May 06, 2013 7:03 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
RE: Database Access
Posted by Vijayendra Bhamidipati <vi...@citrix.com>.
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
RE: Database Access
Posted by Soheil Eizadi <se...@infoblox.com>.
Hi Chip,
At this time we are coming up to speed on the CloudStack architecture, so that we can create an internal PoC which integrates Infoblox services.
-Soheil
________________________________________
From: Chip Childers [chip.childers@sungard.com]
Sent: Monday, May 06, 2013 5:05 PM
To: dev@cloudstack.apache.org
Subject: Re: Database Access
On Tue, May 07, 2013 at 12:00:35AM +0000, Soheil Eizadi wrote:
> 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
I'll let more qualified people reply to the specific question you asked,
but would love to hear more about the work you are doing with CloudStack.
Can I assume that you are looking at integrating infoblox into ACS? If so,
what services are you working on integrating?
-chip
Re: Database Access
Posted by Chip Childers <ch...@sungard.com>.
On Tue, May 07, 2013 at 12:00:35AM +0000, Soheil Eizadi wrote:
> 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
I'll let more qualified people reply to the specific question you asked,
but would love to hear more about the work you are doing with CloudStack.
Can I assume that you are looking at integrating infoblox into ACS? If so,
what services are you working on integrating?
-chip