This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?
I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1
Cheers,
Jody
On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:
Hi all,
Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.
This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?
Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.
I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1
We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.
Cheers,
Jody
On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:
Hi all,
Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.
Thanks for the extra detail; I assume you mean “GeoserverDAO” and not “GeosrverDAO”?
No you have a link that is consistent … why the odd speling?
Oh wait the link goes to a GeoServerDOA class (ha ha you are driving me nuts).
So if I read the code right - the GeoServerDOA has:
setGlobal( GeoServerInfo ); // save the global configuration - so is this used when the object is created by the loading code?
save( GeoServerInfo ); // save after modification - used from the ui to save I guess
getGlobal(); // the global GeoServer configuration
So yeah that is a clear hibernate style data access object api; looks good. Internally I imagine it unpacks the GeoServerInfo and does what is needed.
Is there anyway for you github links to highlight what you have changed? I was trying to see where the origional was modified to use the DOA.
Still these are clear; thanks for taking up this ball and moving it forward.
Jody
On 15/10/2010, at 10:39 AM, Justin Deoliveira wrote:
This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?
Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.
I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1
We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.
Cheers,
Jody
On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:
Hi all,
Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.
Thanks for the extra detail; I assume you mean “GeoserverDAO” and not “GeosrverDAO”?
No you have a link that is consistent … why the odd speling?
Oh wait the link goes to a GeoServerDOA class (ha ha you are driving me nuts).
So if I read the code right - the GeoServerDOA has:
setGlobal( GeoServerInfo ); // save the global configuration - so is this used when the object is created by the loading code?
save( GeoServerInfo ); // save after modification - used from the ui to save I guess
getGlobal(); // the global GeoServer configuration
setGlobal() is more used on startup and not really meant to be called by client code. But it could be.
So yeah that is a clear hibernate style data access object api; looks good. Internally I imagine it unpacks the GeoServerInfo and does what is needed.
Is there anyway for you github links to highlight what you have changed? I was trying to see where the origional was modified to use the DOA.
You can look at the github commits which show the diffs but there are alot of them. But the entire patch is available on the jira issue that is linked from the proposal.
This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?
Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.
I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1
We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.
Cheers,
Jody
On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:
Hi all,
Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.
You can also get a diff between two branches on master by using the branch list link on the main page for a project. For Justin’s geoserver mirror, this goes to http://github.com/jdeolive/geoserver/branches
You can also diff between specific revisions, but you have to hand-edit the diff URL for that (replace the name of the from or to branch with the SHA1 sum). You could use the network graph to find the checksum for the revision where wicket14 branched off, producing this permalink to the list of changesets: http://github.com/jdeolive/geoserver/compare/3f4d57f4885639cb3d43bad23d5351953f3e0a01…wicket_14
Thanks for the extra detail; I assume you mean “GeoserverDAO” and not “GeosrverDAO”?
No you have a link that is consistent … why the odd speling?
Oh wait the link goes to a GeoServerDOA class (ha ha you are driving me nuts).
So if I read the code right - the GeoServerDOA has:
setGlobal( GeoServerInfo ); // save the global configuration - so is this used when the object is created by the loading code?
save( GeoServerInfo ); // save after modification - used from the ui to save I guess
getGlobal(); // the global GeoServer configuration
setGlobal() is more used on startup and not really meant to be called by client code. But it could be.
So yeah that is a clear hibernate style data access object api; looks good. Internally I imagine it unpacks the GeoServerInfo and does what is needed.
Is there anyway for you github links to highlight what you have changed? I was trying to see where the origional was modified to use the DOA.
You can look at the github commits which show the diffs but there are alot of them. But the entire patch is available on the jira issue that is linked from the proposal.
This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?
Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.
I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1
We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.
Cheers,
Jody
On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:
Hi all,
Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev