Re: [Geoserver-devel] hibernate configuration module status

[Justin D. <jde...@op...>]

Well the current hibernate module you can engage via profile, -P hibernate.
However the stuff i have been doing is not in the svn repo yet. But the same
applies it is engagable via a profile. In the version in my git repo i
renamed the module to "dbconfig" as "hibernate" seemed a bit too generic.
Also soon we will require a generic hibernate module i think since we have
dbconfig and monitoring both using hibernate and it would be nice to factor
out common code.

On Thu, Sep 30, 2010 at 7:59 AM, David Winslow <dwi...@op...> wrote:

> Are there instructions anywhere for running against the Hibernate backend?
>
> -d
>
>
> On Thu, Sep 30, 2010 at 6:35 AM, Simone Giannecchini <
> sim...@ge...> wrote:
>
>> Ciao Justin,
>> I have had an  email in draft for a week now about the Hib topic, so I
>> better start answering to this one.
>>
>> A few notes:
>>
>> -1- emanuele is not going to be able to spend time on this very soon,
>> but we were planning to back to this topic towards the end of the year
>> -2- I am not sure I will have enough time to check the code myself and
>> anyway I am not sure I can be of any help anymore :).
>>
>> However, you need to be aware that the real problem with having a
>> db-based config for the geoserver
>> is the assumption that is made  all over the codebase that things sits
>> in memory. I am sure we can find a
>> workaround that would not require to change all the code that interact
>>  with the catalog but that migh sound like a hack.
>> In our view the catalog implementation should be more pluggable and
>> should address for searching and paging right at the core.
>>
>> As I said, I have not looked at the code you have put together, but
>> what I wanted to ask is as follows:
>>
>> - Can we see some design/idea/anything about what you want to do? We
>> have spent quite some time/money on the Hib prototype and I would make
>> sure it is being evolved in the right direction before we pick it up
>> again for our objectives
>> - What is the effort that your mandate allow to spend on this Hib
>> thing? I doubt we can solve this problem once for all in a couple of
>> weeks, providing also that emanuele's feedback will be almost absent.
>> As an instance, we had to almost avoid lazy loading with the Hib
>> catalog in order to make it usable with the UI withouth changing the
>> UI itself, thereore the model and config might need to be tweaked a
>> bit, etc. etc.
>>
>>
>> Ciao,
>> Simone.
>> -------------------------------------------------------
>> ===
>> Notice that our office phone number has recently changed!
>> Please, update your records!
>> ===
>> Ing. Simone Giannecchini
>> GeoSolutions S.A.S.
>> Founder
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584962313
>> fax:      +39 0584962313
>> mob:    +39 333 8128928
>>
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.linkedin.com/in/simonegiannecchini
>> http://twitter.com/simogeo
>>
>> -------------------------------------------------------
>>
>>
>>
>> On Thu, Sep 30, 2010 at 2:07 AM, Justin Deoliveira <jde...@op...>
>> wrote:
>> > Hi all,
>> > Over the past week I have been working on the hibernate configuration
>> > community module. I wanted to send a quick status update to let people
>> know
>> > where things are at.
>> > So first off my goal here is to get the db backed configuration working
>> with
>> > GeoServer as seamlessly as possible. If there is anything that I learned
>> > from the configuration changeover that happened in 2.0 it is that
>> > backwards compatibility needs to be paramout. So I set out with the goal
>> > that no test cases and no client code should have to change in order to
>> work
>> > with the new catalog and config. Nice in theory :) but in practice some
>> code
>> > does have to change, but that is places where tests or client code make
>> bad
>> > assumptions. But all in all these cases are very few.
>> > In order to verify this I hacked up locally a testing configuration that
>> > allowed me to run all the geoserver integration tests (tests that extend
>> > from GeoServerTestSupport) against the hibernate backed config rather
>> than
>> > the classic in memory one. This was a lot of work to setup but it really
>> > paid off since as you can imagine it fleshed out a lot of bugs with the
>> db
>> > config. And I am happy to report that all the test cases pass!! I also
>> ran
>> > all cite tests successfully.
>> > To get to this point I picked up the hibernate module where Emanuele
>> left it
>> > off and completed the refactor we discussed. The refactor in question
>> was to
>> > come up with a dao interface for the catalog and config and have a
>> single
>> > catalog/config implementation. I took Emanuele's initial work and moved
>> as
>> > much logic out of the daos and into the catalog/config as i could. This
>> was
>> > done for (a) backwards compatibility reasons, to keep the same logic as
>> > before regardless of the dao and for (b) maintainability reasons, to
>> keep
>> > that logic in a single central place.
>> > I also removed any customized beans for hibernate and got around those
>> > issues other ways. Having custom beans for hibernate was problematic in
>> that
>> > it leaked out bean implementation details and creation logic over the
>> > codebase, the worst case being in the xstream persistence and
>> restconfig. So
>> > i opted to make changes to the core beans themselves when needed and
>> > workaround the issues with other methods. Now i am not saying that at
>> some
>> > point we won't need custom hibernate beans but I think it should be a
>> last
>> > ditch effort.
>> > Finally the changes are available in my geoserver github repo:
>> >   http://github.com/jdeolive/geoserver/tree/catalog_dao
>> > Now all the above is great but it is only level 0. I am taking a "first
>> make
>> > it work and then make it fast and scalable" approach. With a working
>> > implementation the plan is now to stress test it since the whole point
>> of
>> > using a db backend is to be able to scale up to millions of layers. This
>> > part however will also involve changes to client code since there are
>> many
>> > places in the code that assume the entire catalog lives in memory.
>> > That said I would like to get the current changes committed and possibly
>> > start getting some testing from other devs and those of our users who
>> are
>> > eager and brave.
>> > Thoughts? Comments? Objections?
>> > -Justin
>> > --
>> > Justin Deoliveira
>> > OpenGeo - http://opengeo.org
>> > Enterprise support for open source geospatial.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Start uncovering the many advantages of virtual appliances
>> > and start using them to simplify application deployment and
>> > accelerate your shift to cloud computing.
>> > http://p.sf.net/sfu/novell-sfdev2dev
>> > _______________________________________________
>> > Geoserver-devel mailing list
>> > Geo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geo...@li...
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.