Hibernate catalog - Breakout IRC needed
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Hibernate catalog - Breakout IRC needed
by Jody Garnett-3
::
Rate this Message:
How did the rest of your meeting go? I only dropped in for part of it ...
Can you post the logs? On Tue, Nov 10, 2009 at 7:53 PM, Simone Giannecchini <simone.giannecchini@...> wrote: > (Ops, just noticed I sent it to the wrong list) > > > Ciao folks, > we are facing some probs with the gs hib catalog integration: we have > created a few patches in the last months which have been sitting > around for a while, therefore we would like to hold a breakout IRC to > gain again some momentum in the development, improve and then commit > the patches in order to move to phase 2 with this work, which means > performance improvements. > > The main point-of-contacts for this chat should be Emanuele Tajariol > and Justin Deoliveira, anyway, I will be around myself and anyone > interested is more than willing to join the chat. > I am proposing to hold the chat tomorrow @ this [1] time on the IRC > GeoServer channel. > > Ciao, > Simone > [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=11&day=10&hour=14&min=0&sec=0&p1=53&p2=240&p3=215&p4=179 > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://simboss.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > > ------------------------------------------------------- > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Hibernate catalog - Breakout IRC needed
by Simone Giannecchini
::
Rate this Message:
Here is the log!
Ciao, Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Wed, Nov 11, 2009 at 10:43 AM, Jody Garnett <jody.garnett@...> wrote: > How did the rest of your meeting go? I only dropped in for part of it ... > Can you post the logs? > > On Tue, Nov 10, 2009 at 7:53 PM, Simone Giannecchini > <simone.giannecchini@...> wrote: >> (Ops, just noticed I sent it to the wrong list) >> >> >> Ciao folks, >> we are facing some probs with the gs hib catalog integration: we have >> created a few patches in the last months which have been sitting >> around for a while, therefore we would like to hold a breakout IRC to >> gain again some momentum in the development, improve and then commit >> the patches in order to move to phase 2 with this work, which means >> performance improvements. >> >> The main point-of-contacts for this chat should be Emanuele Tajariol >> and Justin Deoliveira, anyway, I will be around myself and anyone >> interested is more than willing to join the chat. >> I am proposing to hold the chat tomorrow @ this [1] time on the IRC >> GeoServer channel. >> >> Ciao, >> Simone >> [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=11&day=10&hour=14&min=0&sec=0&p1=53&p2=240&p3=215&p4=179 >> ------------------------------------------------------- >> Ing. Simone Giannecchini >> GeoSolutions S.A.S. >> Founder - Software Engineer >> Via Carignoni 51 >> 55041 Camaiore (LU) >> Italy >> >> phone: +39 0584983027 >> fax: +39 0584983027 >> mob: +39 333 8128928 >> >> >> http://www.geo-solutions.it >> http://geo-solutions.blogspot.com/ >> http://simboss.blogspot.com/ >> http://www.linkedin.com/in/simonegiannecchini >> >> ------------------------------------------------------- >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@... >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > [15:07] <simboss> etj, jdeolive, afabiani: ping [15:07] <afabiani> pong [15:07] <etj> pong [15:08] <jdeolive> howdy [15:08] <jdeolive> shall we talk catalog? [15:08] <etj> y [15:10] <simboss> etj the floor is yours [15:10] * etj was looking for the jira entries [15:10] <etj> ok np [15:11] <etj> atm the hib catalog isn't compiling [15:11] <etj> as it is when checked out from svn repo [15:11] <etj> since a change in the trunk is requires [15:12] <etj> a jira was filed for it [15:12] <etj> but justin pointed out some issues about it [15:12] <etj> first of all, the fact that the hib catalog just dups some of hte info beans [15:13] <jdeolive> do you have a link to the jira? [15:13] <etj> cant find it here, sry, atm I'm working very far from my usual place [15:13] <etj> I dont have my links at hand [15:14] <jdeolive> np [15:14] <jdeolive> i think i remember the issue [15:14] <etj> k [15:14] <jdeolive> but yeah, to me the duplication seems like the main problem [15:14] <jdeolive> i think what would be ideal [15:15] <etj> the other major problem was about the changes in XStreamPersister [15:15] <jdeolive> is if we 1) isolate what the problems with using the beans as is are [15:15] <jdeolive> 2) change them in cases where we can [15:15] <jdeolive> 3) subclass only when it is needed [15:15] <jdeolive> there is also duplication [15:15] <jdeolive> at the catalog level [15:15] <etj> ok to all 3 pts for me [15:15] <jdeolive> which i think will be problematic as well in terms of maintainance [15:16] <jdeolive> for instance, with the resource pub work many changes are required to the catalog [15:16] <jdeolive> they will be doubled [15:16] == ingenieroariel [n=ingenier@...] has joined #geoserver [15:16] == epickle [n=epickle@...] has joined #geoserver [15:16] <simboss> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=etj_ [15:16] <sigq> Title: Issue Navigator - jira.codehaus.org (at jira.codehaus.org) [15:16] <simboss> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&assigneeSelect=specificuser&assignee=etj_ [15:16] <jdeolive> etj: cool, so what will be the best way to figure out what is wrong with the current beans? [15:16] == bmmpxf [n=mike@...] has joined #geoserver [15:16] <sigq> Title: Issue Navigator - jira.codehaus.org (at jira.codehaus.org) [15:17] <etj> k, but I'd rather stick to have somthing compiling and runing atm [15:17] <jdeolive> etj: sure [15:17] <jdeolive> do you have a log of the compliation errors? [15:17] == doktoreas [n=doktorea@...] has quit [Read error: 145 (Connection timed out)] [15:17] <jdeolive> or is that another jira? [15:17] <etj> the other issue was about the XStreamPersister [15:18] <etj> even if we merge the *Info beans [15:18] <etj> we also need custom converters [15:19] <etj> in order to have the hibernate Collections properly encoded [15:19] <etj> i.e. PersistentList, PersistentMap and so on [15:19] <jdeolive> ahh ok [15:19] <jdeolive> so the issue is [15:19] <etj> or xstream will just extract useless data from them through introspection [15:19] <jdeolive> yeah, but we should be able to configure that [15:20] <jdeolive> and add support directly for the hibernate collections [15:20] <jdeolive> but yeah... i guess some flag or something will need to exist [15:20] <jdeolive> to switch what will be the default [15:20] <etj> I implemented a way to inject into the XStreamPersister [15:20] <etj> the needed converters [15:20] <etj> only when the hibernate profiled is specified in mvn [15:21] <etj> using straight spring injection [15:21] <etj> it's in the proposed patch [15:22] <jdeolive> yeah... i was not really crazy about the idea of introducing a new interface... but i admit i may have to come around [15:22] <etj> even if the current implementation will also change the defaultimplementation for the beans [15:22] <jdeolive> seemed like maybe some subclassing may be simpler [15:22] <jdeolive> but i admit i don't have the same understanding of the problem [15:23] <etj> uhm, I'm afraid subclassing won't do [15:23] <etj> beacuse XStreamPersister is not instatntiated and injected by spring [15:23] <jdeolive> we could change that [15:23] <etj> but it is created by calling new [15:23] <etj> could do [15:24] <etj> my main aim was not to make too big changes to the trunk, when I wrote the patch [15:24] <jdeolive> yup, understood [15:24] <jdeolive> but i think we can't get around doing that if we want to do this properly [15:24] <jdeolive> so my motivation [15:25] <jdeolive> is to figure out what the cahnges to trunka re needed [15:25] <jdeolive> so this work can be done as cleanly as possible [15:25] <jdeolive> but i understand you guys have deadlines [15:25] <etj> the issue was not about deadlines, but by changing less things as possible, since gs was in RC then [15:26] <jdeolive> right, that too [15:26] <simboss> my goal is to have this done in the quickest and cleanest way :-) [15:26] <jdeolive> which technically on 2.0.x is still a restriction [15:26] <simboss> so that we can move forward with the rest of the things we got to do [15:26] <jdeolive> question: [15:26] <jdeolive> does this work have to be done on 2.0.x? [15:27] <jdeolive> or can we start working on trunk where we have a bit more freedom [15:28] <simboss> we need 2.0.x as well [15:28] <jdeolive> simboss: does the current implementation work well enough on 2.0.x? [15:28] <simboss> not bad [15:28] <simboss> but we need to move on the next steps [15:29] <simboss> as I briefly told you down under [15:29] <simboss> enhancing a bit the catalog, improving the ui [15:29] <simboss> I am aware that some of these changes [15:30] <simboss> will be difficult to push into 2.0.x [15:30] <jdeolive> yeah [15:30] <simboss> due to the fact that they require changes to the (internal) API [15:30] <aaime> right [15:30] <simboss> but I need to push as much as possible [15:30] <simboss> I am tired of having to maintain patches and internal branches [15:31] <aaime> the frustration is understandable, but at the same time we cannot destabilize 2.0 just released with massive changes [15:31] <aaime> it took months to get it into shape [15:32] <simboss> that is why we are taking small steps in the desirable direction [15:32] <simboss> I know where I want to go [15:32] <simboss> andwe more or less know how [15:32] <simboss> we are trying to make out patch match where geoserver is going :-) [15:32] <aaime> so the idea would be to make compromises on 2.0.x to have a pluggable catalog [15:32] <aaime> and do the full thing on trunk? and maybe have hiberante catalog become the default there? [15:33] <aaime> (just trying to get an understanding) [15:33] <jdeolive> we were trying to get to the understanding :) [15:33] <simboss> jdeolive what is the timeline for your pub/res split work? [15:33] <aaime> sorry, go ahead, I jumped in the middle of the discussion [15:33] <jdeolive> simboss: well the resource pub work is (now) targetted at 2.1.x [15:33] <jdeolive> so still far off [15:34] <simboss> mmmhhh [15:34] <simboss> thinking [15:34] <jdeolive> but i hoped to start working on trunk soon [15:34] <aaime> far off == 6 months? [15:34] <aaime> (for a stable 2.1 I mean) [15:34] <simboss> let's me explain [15:34] <jdeolive> at least... probably closer to a year if history teaches me anything [15:34] <simboss> as you might imagine [15:34] <simboss> 1 year [15:35] <simboss> does not look like a deadline I can make use of :-) [15:35] <simboss> let me explain [15:35] <simboss> we have many installations of geoserver [15:35] <simboss> that we maintain [15:36] <simboss> and they all more or less use cutting edge customizations from us [15:36] <simboss> therefore I can accept a certain degree of instability [15:36] <jdeolive> fair enough [15:36] <jdeolive> but its hard to work within the framework you guys need [15:36] <simboss> (those usually test things that later one we try to drop to trunk of gt and/or gs, like gdal, jpeg2lk etc..) [15:36] <jdeolive> where you have to do major work, but it has to be done asap on a stable branch [15:36] <jdeolive> so finding the compromise is a challenge :) [15:36] <simboss> but I cannot shoot at a moving target :-) [15:37] <simboss> exact [15:37] <simboss> my goal atm [15:37] <simboss> is to have the hibernate catalog [15:37] <simboss> compiling [15:37] <simboss> on 2.0x [15:37] <simboss> and trunk [15:37] <simboss> (this is why I called this IRC breakout) [15:37] <simboss> and then start playing with the next changes we discussed a bit [15:38] <simboss> (we are going to make gsip and everything) [15:38] <simboss> which means [15:38] <simboss> support for pagination in catalog methods [15:38] == juliatorti [n=juliator@...] has joined #geoserver [15:38] <simboss> as well as refinements in the hibernate mappings as well as in how the Ui interacts with the catalog itself [15:39] <aaime> (pagination alone won't be enough, you need filtering and sorting too) [15:39] <simboss> yep, that's how I call that part of the work [15:39] * etj and aaime already talked a bit about it [15:39] <simboss> :-) [15:39] <jgarnett> suggestion: simboss is the moving target (use trunk and release a stable when done) [15:40] <simboss> jgarnett: yeah, that is why I was asking jdeolive about the next thing on the plate [15:41] <jgarnett> I would find it kinder to everyone to release a 2.1 earlier then a year; then to try and backport new work into 2.0 [15:41] <jdeolive> jgarnett: a year was not based on the impact of the work [15:41] <jdeolive> it was based on the previous major releases [15:41] <jdeolive> we put at a major release about once a year no? [15:41] <jgarnett> agreed; I understood your argument. [15:42] <aaime> any time we do major changes it takes months to get it back into shape [15:42] <aaime> trunk will be hit by 3 major changes in a row afaik [15:42] <jgarnett> it is not a hard and fast rule; I would rather not see major changes smack a stable release around if we can avoid it. [15:42] <aaime> hibernate catalog, resoure/publish split, wcs nd [15:43] <simboss> thinking... I think that the best thing atm would be [15:43] <simboss> to find a way to [15:43] <jgarnett> can we make three releases; ie step up the pace to match incoming? [15:43] <aaime> so even if I hope for a shorter reelease cycle this time [15:43] <aaime> jdeolive has all the reasons to think about a year instead [15:43] <simboss> cope with ETj issues [15:43] <simboss> and then come back here in 2-3 weeks [15:43] <jgarnett> (I cannot stay and chat; will read logs when done :-( ) [15:44] == iwillig [n=ivan@...] has quit ["leaving"] [15:44] <jdeolive> simboss: sounds good, i have some ideas about how we may need to work as well [15:44] <simboss> and set out a clear path for the future [15:44] <jdeolive> and i draw this from how the catalog and config work was done last tiem around [15:44] <simboss> I am also willing to fund some of your guys time [15:44] <simboss> to help out on this [15:44] <simboss> what do you think? [15:45] <jdeolive> (i also have some permission to put some in kind time in as well from my employer) [15:45] <jdeolive> my thought [15:45] <jdeolive> is to mirror how i managed the catalog change over [15:45] <jdeolive> basically on trunk i was free to use the new catalog apis, do things cleanly [15:45] <jdeolive> but on the stable branch we always had to work around that in order to keep things stable [15:46] <jdeolive> so its still branch development i guess [15:46] <jdeolive> but in this case we could do the improvements we need to for the hib catalog on trunk the clean way [15:46] <jdeolive> and backport to 2.0.x [15:46] <jdeolive> in a way that won't affect stability [15:46] <simboss> that would work I guess [15:46] <simboss> I can even make things easier [15:46] <simboss> as long as we isolate the changes [15:46] <simboss> I can even work with the geoserver trunk [15:47] <simboss> since I would control over the instability [15:47] <simboss> and I could still use that for the most prototypal deployments [15:47] <simboss> does it make sense? [15:47] <simboss> this is why [15:47] <jdeolive> that is anotehr option as well, to agree to only have one major development going on a time and queue them up [15:47] <simboss> exact [15:47] <simboss> I was saying, this is why I said, let's remove th obstacle we have in front now [15:48] <jdeolive> that would also probably achieve the shorter release cycle we strive for [15:48] <simboss> and plan carefully the wrk ahead in a few weeks [15:48] <jdeolive> sounds good [15:48] <simboss> exactly [15:48] <simboss> as I said [15:49] <arneke> (stupid question: is it completely impossible to support both catalogs for a while, have it be a Spring change which one you use?) [15:49] <jdeolive> arneke: that is how it is set up currently [15:49] <jdeolive> but we have sort of reached the limit on keeping them separate and now some changes are required to the core to make the switchign clean [15:49] <arneke> oh. at least I prefixed it with "stupid" :) [15:49] <jdeolive> not at all :) [15:50] <jdeolive> ok so simboss and etj , let's get you up and running with something compiling and revisit in a couple of weeks? [15:52] <etj> ok, so [15:54] <etj> we'll commit the changes in the 2.0.x branch so that the whole thing will compile and run [15:55] <etj> and will clean the hibernate beans as much as possible in the trunk [15:55] <etj> (it's only a matter "id" and "isDefault" fields) [15:56] <jdeolive> cool, so etj to confirm [15:56] <jdeolive> what commits are reqruired to make things compile? [15:57] <etj> if I remeber right, it was a change in the XStreamPersister [15:57] <etj> plus an Interface and a DefaultImplementation [15:57] <jdeolive> sigh... so yeah, that is what i consider the thing to be cleaned up on trunk [15:58] <etj> for mapping the various gs *Info interfaces to the proper implementations [15:58] <etj> yep [15:58] <etj> I was talking about making the whole thing stable [15:58] <etj> but [15:58] <etj> we may work on the XStreamPersister a bit [15:59] <etj> in order to make generic List works [15:59] <etj> avoiding dependencies to Hibernate classes [16:00] <etj> (sorry for the latency, I'm using a web client) [16:00] <jdeolive> np [16:01] <etj> cleaning the hibenrate beans stuff, and writing generic converters to avoid hibernate collections misinterpretation [16:01] <jdeolive> ok [16:02] <etj> the thing should be cleaned a bit [16:03] <jdeolive> ok sounds good, well i will await your next steps [16:03] <jdeolive> i have to run to another meeting now [16:03] <jdeolive> thanks for the chat giuys [16:03] <etj> oky jdeolive [16:04] <etj> thank you all ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
| Free embeddable forum powered by Nabble | Forum Help |
