[Geoserver-devel] Some thoughts on the config subsystem

[Andrea_Aime3]

Hi,
a little rant on the current and new config subsystems.

The current one is... well, let's just say that throwing it
away would be an act of mercy, and be done with it. It's blocking
our evolution in every direction that requires new configuration
elements.

The one proposed in the Refractions funded study looks better,
yet forgets again configuration info mantainance. Let me elaborate
this. The new prototype is hibernate based. Hibernate is an O/R mapper
that allows you to write an application in OO terms and be independent
of the underlying DB. It can create the DB schema for you.
Storing config in a database allows for easy clustering.
Isn't it great? Well, I'll tell you what: no, it's not, from
a database maintainance point of view it is not.

I've adopted Hibernate when it was 0.8.1 and developed applications
based on it for four years before joining Geoserver, so to some
extent I know what I'm talking about. And what I'm talking about
is schema evolution.
When everything is set into stone, you can use Hibernate to jump
from one db to the other, and it's a neat pleasure.
Yet this very flexibility comes to bite you when it's time to
evolve the schema.

Hibernate has a tool that tries to figure out the alter table
needed (http://www.hibernate.org/hib_docs/v3/reference/en/html/toolsetguide.html#toolsetguide-s1-6).
In my experience, it works fine only with the most trivial changes,
such as adding a nullable field to a bean.
Need to add a new association? Or to add a non nullable field?
Then you have to roll your own alter tables, updates and whatnot.

I had to do that various times with applications in production,
but I had one/two target databases, and the changes where incremental,
so each time I had from 3 to 10 sql statements to execute.

Now, picture a situation in which we ship GeoServer with a
hibernate based configuration. People start deploying it on
4 different database (hsql, mysql, postgres, oracle).
Then we ship Geoserver n+1, which has some (eventual serious) configuration changes. For which database do we hand write
the sql upgrade scripts? Do we test for all of them?
If we're not prepared to do so, then the statement that
the configuration can be stored in various database becomes
a bad joke... our users will have to try out database upgrades
without knowing anything about the code that reads them and
so on. I mean, an issue with database structure alteration will
require someone with a debugger to track down what's going
on.

A file system based config does not have these issues, and
tools like XStream will tolerate schema changes without
much fuss.

I'm not saying we should go in one direction or the other,
just want to make sure we're aware of what are the
consequences of our decisions.

Cheers
Andrea

[Alessio_Fabiani]

Hi Andrea, all,

I fully agree with the difficulties you are experiencing with the actual config subsystem … here we also need something more powerful and flexible even in consideration of the remote management of GeoServer catalog, the management of a big amount of datasets and the support of future nD coverages.

Personally I would prefer the Hibernate approach even if I see your concerns about issues on DB based configuration.

On 7/18/07, Andrea Aime < aaime@anonymised.com> wrote:

Hi,
a little rant on the current and new config subsystems.

The current one is… well, let’s just say that throwing it
away would be an act of mercy, and be done with it. It’s blocking
our evolution in every direction that requires new configuration
elements.

The one proposed in the Refractions funded study looks better,
yet forgets again configuration info mantainance. Let me elaborate
this. The new prototype is hibernate based. Hibernate is an O/R mapper
that allows you to write an application in OO terms and be independent
of the underlying DB. It can create the DB schema for you.
Storing config in a database allows for easy clustering.
Isn’t it great? Well, I’ll tell you what: no, it’s not, from
a database maintainance point of view it is not.

I’ve adopted Hibernate when it was 0.8.1 and developed applications
based on it for four years before joining Geoserver, so to some
extent I know what I’m talking about. And what I’m talking about
is schema evolution.
When everything is set into stone, you can use Hibernate to jump
from one db to the other, and it’s a neat pleasure.
Yet this very flexibility comes to bite you when it’s time to
evolve the schema.

Hibernate has a tool that tries to figure out the alter table
needed
(http://www.hibernate.org/hib_docs/v3/reference/en/html/toolsetguide.html#toolsetguide-s1-6 ).
In my experience, it works fine only with the most trivial changes,
such as adding a nullable field to a bean.
Need to add a new association? Or to add a non nullable field?
Then you have to roll your own alter tables, updates and whatnot.

I had to do that various times with applications in production,
but I had one/two target databases, and the changes where incremental,
so each time I had from 3 to 10 sql statements to execute.

Now, picture a situation in which we ship GeoServer with a
hibernate based configuration. People start deploying it on
4 different database (hsql, mysql, postgres, oracle).
Then we ship Geoserver n+1, which has some (eventual serious)
configuration changes. For which database do we hand write
the sql upgrade scripts? Do we test for all of them?
If we’re not prepared to do so, then the statement that
the configuration can be stored in various database becomes
a bad joke… our users will have to try out database upgrades
without knowing anything about the code that reads them and
so on. I mean, an issue with database structure alteration will
require someone with a debugger to track down what’s going
on.

A file system based config does not have these issues, and
tools like XStream will tolerate schema changes without
much fuss.

I’m not saying we should go in one direction or the other,
just want to make sure we’re aware of what are the
consequences of our decisions.

Cheers
Andrea

---

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000

http://www.geo-solutions.it

---

[Andrea_Aime3]

Alessio Fabiani ha scritto:

Hi Andrea, all,

I fully agree with the difficulties you are experiencing with the actual config subsystem ... here we also need something more powerful and flexible even in consideration of the remote management of GeoServer catalog, the management of a big amount of datasets and the support of future nD coverages.

Personally I would prefer the Hibernate approach even if I see your concerns about issues on DB based configuration.

Well, my concerns can be addressed various ways:
* we do support most common databases, thus issue update scripts for
   most databases (I don't think we can have the resources for it)
* we tell people if they use any db other than HSQL they are on
   their on at the first upgrade

Either sounds quite unacceptable to me. A possible alternative could
be that we go thru an XML export and and import at each upgrade, that is:
* export from Geoserver n-1 into xml format (using xstream or xmlbeans)
* wipe out the current config db (drop all tables)
* fire up Geoserver n+1 and let it create a new emtpy db (this is done
   properly by hibernate)
* import from XML, and have the import procedures handle the
   differences.

Hmm... this sounds like a more reasonable way. We should also keep verion numbers of the config schema around (both in the xml and in the database).

Cheers
Andrea

[Justin_Deoliveira]

Hi Andrea,

Good rant :). However there is something that should be clarified. The real point of the configuration prototype was to come up with a better model/interfaces for the configuration then the one we have today.

You did not mention the fact that the prototype also has an xml based (xstream) persistence layer which is similar to what we have today. One of the points of the entire exercise was to show we could design a configuration model which was orthogonal to the persistence mechanism we use. Hibernate was just a proof of concept to show that we could also back this thing onto a database.

I may be mistaken but I thought the plan would (if a new config system ever happens) to ship with out of the box with the xml based persistence similar to what we have today and then give advanced users the option of using hibernate.

-Justin

Andrea Aime wrote:

Hi,
a little rant on the current and new config subsystems.

The current one is... well, let's just say that throwing it
away would be an act of mercy, and be done with it. It's blocking
our evolution in every direction that requires new configuration
elements.

The one proposed in the Refractions funded study looks better,
yet forgets again configuration info mantainance. Let me elaborate
this. The new prototype is hibernate based. Hibernate is an O/R mapper
that allows you to write an application in OO terms and be independent
of the underlying DB. It can create the DB schema for you.
Storing config in a database allows for easy clustering.
Isn't it great? Well, I'll tell you what: no, it's not, from
a database maintainance point of view it is not.

I've adopted Hibernate when it was 0.8.1 and developed applications
based on it for four years before joining Geoserver, so to some
extent I know what I'm talking about. And what I'm talking about
is schema evolution.
When everything is set into stone, you can use Hibernate to jump
from one db to the other, and it's a neat pleasure.
Yet this very flexibility comes to bite you when it's time to
evolve the schema.

Hibernate has a tool that tries to figure out the alter table
needed (http://www.hibernate.org/hib_docs/v3/reference/en/html/toolsetguide.html#toolsetguide-s1-6).
In my experience, it works fine only with the most trivial changes,
such as adding a nullable field to a bean.
Need to add a new association? Or to add a non nullable field?
Then you have to roll your own alter tables, updates and whatnot.

I had to do that various times with applications in production,
but I had one/two target databases, and the changes where incremental,
so each time I had from 3 to 10 sql statements to execute.

Now, picture a situation in which we ship GeoServer with a
hibernate based configuration. People start deploying it on
4 different database (hsql, mysql, postgres, oracle).
Then we ship Geoserver n+1, which has some (eventual serious) configuration changes. For which database do we hand write
the sql upgrade scripts? Do we test for all of them?
If we're not prepared to do so, then the statement that
the configuration can be stored in various database becomes
a bad joke... our users will have to try out database upgrades
without knowing anything about the code that reads them and
so on. I mean, an issue with database structure alteration will
require someone with a debugger to track down what's going
on.

A file system based config does not have these issues, and
tools like XStream will tolerate schema changes without
much fuss.

I'm not saying we should go in one direction or the other,
just want to make sure we're aware of what are the
consequences of our decisions.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,469dc3c9216002458217002!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Hi Andrea,

Good rant :). However there is something that should be clarified. The real point of the configuration prototype was to come up with a better model/interfaces for the configuration then the one we have today.

You did not mention the fact that the prototype also has an xml based (xstream) persistence layer which is similar to what we have today.

I did not remember there was one, sorry

One of the points of the entire exercise was to show we could design a configuration model which was orthogonal to the persistence mechanism we use. Hibernate was just a proof of concept to show that we could also back this thing onto a database.

I may be mistaken but I thought the plan would (if a new config system ever happens) to ship with out of the box with the xml based persistence similar to what we have today and then give advanced users the option of using hibernate.

Hmm... I fear that may not work? Hibernate persistence mappings/annotations should be kept up to date as we evolve the configuration, who's going to do that and check everything is still
working if Hibernate is not in by default?

Cheers
Andrea

[Justin_Deoliveira]

Hmm... I fear that may not work? Hibernate persistence mappings/annotations should be kept up to date as we evolve the configuration, who's going to do that and check everything is still
working if Hibernate is not in by default?

Agreed... It would be something we would have to maintain... although given the amount of work it is to add a config option today it should be childs play

Cheers
Andrea

!DSPAM:4007,469e355e306271637810514!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

[jive]

Hi Andrea;

The part of the config proposal that is important to me is the clear separation between the config layer and the rest of the application. There are two sample implementations (XML and hibernate+h2). If possible I would like to focus on this separation of concerns rather than specific problems with hibernate.

For the clustering solution it was my intention to write a config system based on EJB3; I am stuck on the geotools referencing module and have been unable to start that work. I understand that there is a little difference between EJB3 and Hibernate - so I am interested in your experience.

As you know the previous configuration system suffered whenever we tried to add additional configuration options (most of this suffering as in updating seven different Java files - but at least the configuration files were backwards compatible). For the new configuration system we tried to address this extensibility as a first class concern; allowing for the fact that additional configuration settings would need to be added over time. The solution shows up in the API in a manner similar to JComponent.getClientProperties - that is the configuration options may / or may not be strongly typed. Additional methods can be added to the interface and implemented with the get/set properties idea.

With this in mind even the hibernate based solution should not break over time.
Jody

Hi,
a little rant on the current and new config subsystems.

The current one is... well, let's just say that throwing it
away would be an act of mercy, and be done with it. It's blocking
our evolution in every direction that requires new configuration
elements.

The one proposed in the Refractions funded study looks better,
yet forgets again configuration info mantainance. Let me elaborate
this. The new prototype is hibernate based. Hibernate is an O/R mapper
that allows you to write an application in OO terms and be independent
of the underlying DB. It can create the DB schema for you.
Storing config in a database allows for easy clustering.
Isn't it great? Well, I'll tell you what: no, it's not, from
a database maintainance point of view it is not.

I've adopted Hibernate when it was 0.8.1 and developed applications
based on it for four years before joining Geoserver, so to some
extent I know what I'm talking about. And what I'm talking about
is schema evolution.
When everything is set into stone, you can use Hibernate to jump
from one db to the other, and it's a neat pleasure.
Yet this very flexibility comes to bite you when it's time to
evolve the schema.

Hibernate has a tool that tries to figure out the alter table
needed (Page Redirection).
In my experience, it works fine only with the most trivial changes,
such as adding a nullable field to a bean.
Need to add a new association? Or to add a non nullable field?
Then you have to roll your own alter tables, updates and whatnot.

I had to do that various times with applications in production,
but I had one/two target databases, and the changes where incremental,
so each time I had from 3 to 10 sql statements to execute.

Now, picture a situation in which we ship GeoServer with a
hibernate based configuration. People start deploying it on
4 different database (hsql, mysql, postgres, oracle).
Then we ship Geoserver n+1, which has some (eventual serious) configuration changes. For which database do we hand write
the sql upgrade scripts? Do we test for all of them?
If we're not prepared to do so, then the statement that
the configuration can be stored in various database becomes
a bad joke... our users will have to try out database upgrades
without knowing anything about the code that reads them and
so on. I mean, an issue with database structure alteration will
require someone with a debugger to track down what's going
on.

A file system based config does not have these issues, and
tools like XStream will tolerate schema changes without
much fuss.

I'm not saying we should go in one direction or the other,
just want to make sure we're aware of what are the
consequences of our decisions.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

[jive]

Teach me to read my email; Justin already made this point using less words - sigh.
Cheers,
Jody

Hi Andrea;

The part of the config proposal that is important to me is the clear separation between the config layer and the rest of the application. There are two sample implementations (XML and hibernate+h2). If possible I would like to focus on this separation of concerns rather than specific problems with hibernate.

For the clustering solution it was my intention to write a config system based on EJB3; I am stuck on the geotools referencing module and have been unable to start that work. I understand that there is a little difference between EJB3 and Hibernate - so I am interested in your experience.

As you know the previous configuration system suffered whenever we tried to add additional configuration options (most of this suffering as in updating seven different Java files - but at least the configuration files were backwards compatible). For the new configuration system we tried to address this extensibility as a first class concern; allowing for the fact that additional configuration settings would need to be added over time. The solution shows up in the API in a manner similar to JComponent.getClientProperties - that is the configuration options may / or may not be strongly typed. Additional methods can be added to the interface and implemented with the get/set properties idea.

With this in mind even the hibernate based solution should not break over time.
Jody

Hi,
a little rant on the current and new config subsystems.

The current one is... well, let's just say that throwing it
away would be an act of mercy, and be done with it. It's blocking
our evolution in every direction that requires new configuration
elements.

The one proposed in the Refractions funded study looks better,
yet forgets again configuration info mantainance. Let me elaborate
this. The new prototype is hibernate based. Hibernate is an O/R mapper
that allows you to write an application in OO terms and be independent
of the underlying DB. It can create the DB schema for you.
Storing config in a database allows for easy clustering.
Isn't it great? Well, I'll tell you what: no, it's not, from
a database maintainance point of view it is not.

I've adopted Hibernate when it was 0.8.1 and developed applications
based on it for four years before joining Geoserver, so to some
extent I know what I'm talking about. And what I'm talking about
is schema evolution.
When everything is set into stone, you can use Hibernate to jump
from one db to the other, and it's a neat pleasure.
Yet this very flexibility comes to bite you when it's time to
evolve the schema.

Hibernate has a tool that tries to figure out the alter table
needed (Page Redirection).
In my experience, it works fine only with the most trivial changes,
such as adding a nullable field to a bean.
Need to add a new association? Or to add a non nullable field?
Then you have to roll your own alter tables, updates and whatnot.

I had to do that various times with applications in production,
but I had one/two target databases, and the changes where incremental,
so each time I had from 3 to 10 sql statements to execute.

Now, picture a situation in which we ship GeoServer with a
hibernate based configuration. People start deploying it on
4 different database (hsql, mysql, postgres, oracle).
Then we ship Geoserver n+1, which has some (eventual serious) configuration changes. For which database do we hand write
the sql upgrade scripts? Do we test for all of them?
If we're not prepared to do so, then the statement that
the configuration can be stored in various database becomes
a bad joke... our users will have to try out database upgrades
without knowing anything about the code that reads them and
so on. I mean, an issue with database structure alteration will
require someone with a debugger to track down what's going
on.

A file system based config does not have these issues, and
tools like XStream will tolerate schema changes without
much fuss.

I'm not saying we should go in one direction or the other,
just want to make sure we're aware of what are the
consequences of our decisions.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

[Andrea_Aime3]

Jody Garnett ha scritto:

Hi Andrea;

The part of the config proposal that is important to me is the clear separation between the config layer and the rest of the application. There are two sample implementations (XML and hibernate+h2). If possible I would like to focus on this separation of concerns rather than specific problems with hibernate.

For the clustering solution it was my intention to write a config system based on EJB3; I am stuck on the geotools referencing module and have been unable to start that work. I understand that there is a little difference between EJB3 and Hibernate - so I am interested in your experience.

This will have to be maintained over time. Who's going to do it?
EJB3 means more or less nothing until you back it with a library.
Plus, remember the SENS experience, we targed annotations, that were
pure EJB3, and had to use various Hibernate extensions to make things
work for real (collections with orphan deletions for example).

As you know the previous configuration system suffered whenever we tried to add additional configuration options (most of this suffering as in updating seven different Java files - but at least the configuration files were backwards compatible). For the new configuration system we tried to address this extensibility as a first class concern; allowing for the fact that additional configuration settings would need to be added over time. The solution shows up in the API in a manner similar to JComponent.getClientProperties - that is the configuration options may / or may not be strongly typed. Additional methods can be added to the interface and implemented with the get/set properties idea.

With this in mind even the hibernate based solution should not break over time.

It won't break if you add a property in that map, no, but it will break
as soon as you need a new association, new objects and so on. But
yeah, it'll ease your life for trivial changes.

Cheers
Andrea

[Rob_Atkinson]

IMHO we should consider a registry-based config model.

If you look at the set of artefacts managed by a configuration, most of this would logically be re-usable peices managed in an external catalog for any externally defined data product. And other than WMS, the reality is that only externally defined data products are likely to be useful to clients. Even if a "ad-hoc" synthetic feature type is derived from the data store, as soon as a client starts using it they will want it defined in a stable fashion, external to the vagaries of UI interaction (i.e. it will need to become an externally managed config)

So, we should simply accept that the persistence layer needs to be abstracted behind and registry, i.e. use JAXR. You could build a "private automatically generated registry" using hibernate as a JAXR provider.

Rob Atkinson

Andrea Aime wrote:

Justin Deoliveira ha scritto:
  

Hi Andrea,

Good rant :). However there is something that should be clarified. The real point of the configuration prototype was to come up with a better model/interfaces for the configuration then the one we have today.

You did not mention the fact that the prototype also has an xml based (xstream) persistence layer which is similar to what we have today.
    
I did not remember there was one, sorry

One of the points of the entire exercise was to show we could design a configuration model which was orthogonal to the persistence mechanism we use. Hibernate was just a proof of concept to show that we could also back this thing onto a database.

I may be mistaken but I thought the plan would (if a new config system ever happens) to ship with out of the box with the xml based persistence similar to what we have today and then give advanced users the option of using hibernate.
    
Hmm... I fear that may not work? Hibernate persistence mappings/annotations should be kept up to date as we evolve the configuration, who's going to do that and check everything is still
working if Hibernate is not in by default?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

[jive]

Rob Atkinson wrote:

So, we should simply accept that the persistence layer needs to be abstracted behind and registry, i.e. use JAXR. You could build a "private automatically generated registry" using hibernate as a JAXR provider.

That is interesting I had not met JAXR before; have you used it in a project successfully yet?
Jody

[Rob_Atkinson]

Jody Garnett wrote:

Rob Atkinson wrote:
  

So, we should simply accept that the persistence layer needs to be abstracted behind and registry, i.e. use JAXR. You could build a "private automatically generated registry" using hibernate as a JAXR provider.
    

That is interesting I had not met JAXR before; have you used it in a project successfully yet?
  

Yeah - we have a catalog client component that talks to OGC CSW over ebRIM, ebXML and also a legacy WFS based catalogue.

its there mainly to allow ebXML or UDDI of course, but the principle of the thing is what matters.

Rob

Jody

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

[Simone3]

Hi guys,
I would like to share some thoughts me and alessio have had about the
configuration thing since as e said we are having problems with the actual
one as well.

I have to admit I am all for a db-backed solution and I would not mind the
second solutions aaime is suggesting since between all the commercial system
I have tried this solution seems the most used and accepted. Maybe I am
wrong but I don't see the wipe-out and rebuild db solution as a threat for
users. We could still make XML the standard and leave db to the advanced
ones.

I somehow agree with Rob when he talks about using a registry to keep the
configuration and interact with it through a JAXR provider. There is one
problem though, performance. Using a registry we would add a lot of
indirection layers between the OWS services and the configuration. We are
using OMAR through JAXR for a project for ESA and I can say that even if the
separation between different components is optimal performances are not that
great. While this approach would be IMHO an overkill for small non clustered
deployments it would work just great (together with some caching) for big
clustered deployments.

The way I see it would be that JAXR+registry could be an alternative to
palin xml or good-old db. We would have like different solutions to scale at
different deployment sizes.

Small --> xml files

Medium --> db

Big --> JAXR + clustering

I might be talking non sense given that is so late, but this thread is
pretty interesting and I would love seeing more ideas from real world
experiences.

Ciao,
Simone.

aaime wrote:

Alessio Fabiani ha scritto:

Hi Andrea, all,

I fully agree with the difficulties you are experiencing with the actual
config subsystem ... here we also need something more powerful and
flexible even in consideration of the remote management of GeoServer
catalog, the management of a big amount of datasets and the support of
future nD coverages.

Personally I would prefer the Hibernate approach even if I see your
concerns about issues on DB based configuration.

Well, my concerns can be addressed various ways:
* we do support most common databases, thus issue update scripts for
   most databases (I don't think we can have the resources for it)
* we tell people if they use any db other than HSQL they are on
   their on at the first upgrade

Either sounds quite unacceptable to me. A possible alternative could
be that we go thru an XML export and and import at each upgrade, that is:
* export from Geoserver n-1 into xml format (using xstream or xmlbeans)
* wipe out the current config db (drop all tables)
* fire up Geoserver n+1 and let it create a new emtpy db (this is done
   properly by hibernate)
* import from XML, and have the import procedures handle the
   differences.

Hmm... this sounds like a more reasonable way. We should also keep
verion numbers of the config schema around (both in the xml and in the
database).

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
View this message in context: http://www.nabble.com/Some-thoughts-on-the-config-subsystem-tf4101592.html#a11680107
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

[Rob_Atkinson]

I think we perhaps need to separate three different concerns
   1 - management of the artefacts of configuration - the effort required to look after config
   2 - the load time
   3 - the cost of accessing the config once loaded

It strikes me the performance issue relates to 3, and a nice abstraction that allowed registry-managed reusable config pieces to be loaded incrementally, then efficiently accessed in-memory seems to be required.

RobA

Simone.Giannecchini wrote:

Hi guys, I would like to share some thoughts me and alessio have had about the
configuration thing since as e said we are having problems with the actual
one as well.

I have to admit I am all for a db-backed solution and I would not mind the
second solutions aaime is suggesting since between all the commercial system
I have tried this solution seems the most used and accepted. Maybe I am
wrong but I don't see the wipe-out and rebuild db solution as a threat for
users. We could still make XML the standard and leave db to the advanced
ones.

I somehow agree with Rob when he talks about using a registry to keep the
configuration and interact with it through a JAXR provider. There is one
problem though, performance. Using a registry we would add a lot of
indirection layers between the OWS services and the configuration. We are
using OMAR through JAXR for a project for ESA and I can say that even if the
separation between different components is optimal performances are not that
great. While this approach would be IMHO an overkill for small non clustered
deployments it would work just great (together with some caching) for big
clustered deployments.

The way I see it would be that JAXR+registry could be an alternative to
palin xml or good-old db. We would have like different solutions to scale at
different deployment sizes.

Small --> xml files

Medium --> db

Big --> JAXR + clustering

I might be talking non sense given that is so late, but this thread is
pretty interesting and I would love seeing more ideas from real world
experiences.

Ciao,
Simone.

aaime wrote:
  

Alessio Fabiani ha scritto:
    

Hi Andrea, all,

I fully agree with the difficulties you are experiencing with the actual config subsystem ... here we also need something more powerful and flexible even in consideration of the remote management of GeoServer catalog, the management of a big amount of datasets and the support of future nD coverages.

Personally I would prefer the Hibernate approach even if I see your concerns about issues on DB based configuration.
      

Well, my concerns can be addressed various ways:
* we do support most common databases, thus issue update scripts for
   most databases (I don't think we can have the resources for it)
* we tell people if they use any db other than HSQL they are on
   their on at the first upgrade

Either sounds quite unacceptable to me. A possible alternative could
be that we go thru an XML export and and import at each upgrade, that is:
* export from Geoserver n-1 into xml format (using xstream or xmlbeans)
* wipe out the current config db (drop all tables)
* fire up Geoserver n+1 and let it create a new emtpy db (this is done
   properly by hibernate)
* import from XML, and have the import procedures handle the
   differences.

Hmm... this sounds like a more reasonable way. We should also keep verion numbers of the config schema around (both in the xml and in the database).

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel