You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2010/05/11 10:05:55 UTC
Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today
I've updated the report here:
http://wiki.apache.org/incubator/May2010#Wookie
Begin forwarded message:
> From: Bertrand Delacretaz <bd...@apache.org>
> Date: 11 May 2010 08:24:50 GMT+01:00
> To: Incubator General <ge...@incubator.apache.org>
> Subject: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today
> Reply-To: general@incubator.apache.org
>
> Title says all ;-)
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: important todo: remove hibernate
Posted by Randy Watler <wa...@wispertel.net>.
Ross/All:
Actually, I'd prefer to make it as non-intrusive as possible,
(preserving the Active Record Pattern already in place if I can). Of
course, this may not be possible in the end but I think its worth a try.
I'd like to start with 2-3 plugins to prove out a pluggable persistence
component API... say JPA, JCR, and possibly a file or another nosql
implementation.
I'd prefer to do some prototyping first, and then move to a branch once
I can report some success. If some others want to participate, creating
a branch would be required. A branch would also obviously be best for
carrying out reviews as the implementation converges.
All comments and feedback welcome!
Randy
Ross Gardler wrote:
> On 11/05/2010 19:04, Scott Wilson wrote:
>> On 11 May 2010, at 18:53, Randy Watler wrote:
>>
>>> Scott:
>>>
>>> I am willing to take on this project starting immediately if it can
>>> help you guys and I would not be getting in the way of the ongoing
>>> work of others. Like I said, I have to support JCR storage for
>>> Wookie in any case ASAP.
>>
>> That sounds great to me - what do other committers think? I can
>> imagine other implementations where a JCR connection is going to be
>> useful (Sakai comes to mind, for example).
>
> +1 (not to the technology, I don't know about that, but any
> contribution that talks about being pluggable has to be good).
>
> Randy, I imagine this will be a reasonably disruptive task. Do you
> want us to create a branch for you to work against?
>
> Perhaps you need to review the current implementation first...
>
>
> Ross
>
>>> OJB is what Jetspeed uses internally... I would suggest using JPA
>>> unless there is a compelling reason to do otherwise. I only mention
>>> OJB as a plugin candidate that Jetspeed might use in the future,
>>> not an important one that Wookie support natively.
>>
>> OK, that makes sense. JPA, JDO, EmpireDB etc are all in the same
>> category, as relatively straight switches for HIbernate.
>>
>>> I dont have any experience with Thrift+Cayenne, but I'd be happy to
>>> include that configuration/technology stack in any approach.
>>
>> Bryan can probably help there I imagine..?
>>
>>>
>>> Let me know,
>>>
>>> Randy
>>>
>>> Scott Wilson wrote:
>>>> On 11 May 2010, at 18:22, Randy Watler wrote:
>>>>
>>>>
>>>>> Kris/All:
>>>>>
>>>>> Hello... I am currently starting to modify Wookie to use a JCR
>>>>> backend for use in a CMS web site environment. I am also
>>>>> interested in making the solutions pluggable along the way so
>>>>> that other implementations can be used to suit the environment.
>>>>> I am a committer on the Jetspeed project and there is interest
>>>>> there as well, so using the native store there, (OJB), would be
>>>>> ideal. Obviously, this thread has mentioned other candidates!
>>>>>
>>>>> How best can I help you guys here make this happen?
>>>>>
>>>>
>>>> Hi Randy,
>>>>
>>>> The most pluggable we can be the better I reckon. So things like
>>>> JCR, JPA and so on do have an advantage in that they allow
>>>> multiple implementations. However if we can also make it possible
>>>> to have a Thrift connection to Cayenne then that's good too!
>>>>
>>>> I put OJB on the candidate list, but when I looked at the I
>>>> couldn't see much activity (last commit back in 2008) - though
>>>> maybe thats just because its mature. What's your experience of
>>>> OJB in Jetspeed?
>>>>
>>>> - Scott .
>>>>> Randy
>>>>>
>>>>> Kris Popat wrote:
>>>>>
>>>>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>>>>
>>>>>>
>>>>>>> Kris,
>>>>>>>
>>>>>>> When you mentioned building your own file-based solution it
>>>>>>> made me think of the growing "no-SQL" movement. I wonder if
>>>>>>> it might be useful to leverage yet again another Apache
>>>>>>> project, Cassandra: http://cassandra.apache.org/
>>>>>>>
>>>>>>> For "very large-scale" systems (and likely much more
>>>>>>> complicated), is Apache Hadoop: http://hadoop.apache.org/
>>>>>>>
>>>>>>> Probably most know about these, but they are examples of
>>>>>>> key-based and graph-based storage systems, respectively...
>>>>>>> Document-based approaches already exist too, so it may make
>>>>>>> sense to leverage the work done by the CouchDB team:
>>>>>>> http://couchdb.apache.org/
>>>>>>>
>>>>>>> Just thought I'd share that as the first two projects, and
>>>>>>> Wookie, are currently the three up and coming Apache
>>>>>>> projects my organization is tracking most closely. I'm not
>>>>>>> sure who will win the "efficiency/lightweight data store
>>>>>>> war", but in the end, an approach which offers options and
>>>>>>> flexibility for datastore configuration will probably be
>>>>>>> the nicest for the community, but, most difficult to
>>>>>>> accomplish because of the differences between RDBMS and
>>>>>>> Graph-based camps, perhaps Document-based might be a nice
>>>>>>> middle-ground though?
>>>>>>>
>>>>>> Thanks for that, will add them to the list of possibilities
>>>>>> on the wiki. These look very interesting. Best for us is to
>>>>>> find something that slots in easily replacing the current db
>>>>>> middleware that we are using taking issues of robustness,
>>>>>> extensibility, load handling and licensing into
>>>>>> consideration. Will be spending some time on this over the
>>>>>> next few days tinkering and evaluating
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Bryan
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message----- From: Kris Popat
>>>>>>> [mailto:kjpopat@googlemail.com] Sent: May 11, 2010 5:28 AM
>>>>>>> To: wookie-dev@incubator.apache.org Subject: Re: important
>>>>>>> todo: remove hibernate (was Re: Fwd: Several podling
>>>>>>> reports still missing at
>>>>>>> http://wiki.apache.org/incubator/May2010, due today)
>>>>>>>
>>>>>>>
>>>>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>>>>
>>>>>>>>>> I've updated the report here:
>>>>>>>>>>
>>>>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>>>>
>>>>>>>>> +1 to your report.
>>>>>>>>>
>>>>>>>>> A busy quarter.
>>>>>>>>>
>>>>>>>>> I'm largely silent at present due to spending all my
>>>>>>>>> time on http://www.transfersummit.com (people should
>>>>>>>>> come, it's a great conference).
>>>>>>>>>
>>>>>>>>> Once that's out of the way I want to really crack on
>>>>>>>>> with getting rid of hibernate so we can get a release
>>>>>>>>> out the door. In my opinion, we need a release to
>>>>>>>>> really start building community.
>>>>>>>>>
>>>>>>>>> Of course, if someone wants to get cracking on that
>>>>>>>>> before me I'll gladly start a branch for that work and
>>>>>>>>> keep it aligned with trunk for you (asuuming you are
>>>>>>>>> not already a committer).
>>>>>>>>>
>>>>>>>> Yes, that's pretty much the last hurdle.
>>>>>>>>
>>>>>>>> Kris, were you going to put together a list of candidates
>>>>>>>> for replacing Hibernate on the wiki?
>>>>>>>>
>>>>>>> Yes I've looked through some options a couple of weeks ago,
>>>>>>> will pick it up again and put some ideas up.
>>>>>>>
>>>>>>> It might be worth testing a file based solution that I've
>>>>>>> been working on too. I'll put a patch up for people to
>>>>>>> test in a few days time. Will need testing for robustness
>>>>>>> and speed.
>>>>>>>
>>>>>>>
>>>>>>>>> Ross
>>>>>>>>>
>>>>>> Kris
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
Re: important todo: remove hibernate
Posted by Ross Gardler <rg...@apache.org>.
On 11/05/2010 19:04, Scott Wilson wrote:
> On 11 May 2010, at 18:53, Randy Watler wrote:
>
>> Scott:
>>
>> I am willing to take on this project starting immediately if it can
>> help you guys and I would not be getting in the way of the ongoing
>> work of others. Like I said, I have to support JCR storage for
>> Wookie in any case ASAP.
>
> That sounds great to me - what do other committers think? I can
> imagine other implementations where a JCR connection is going to be
> useful (Sakai comes to mind, for example).
+1 (not to the technology, I don't know about that, but any contribution
that talks about being pluggable has to be good).
Randy, I imagine this will be a reasonably disruptive task. Do you want
us to create a branch for you to work against?
Perhaps you need to review the current implementation first...
Ross
>> OJB is what Jetspeed uses internally... I would suggest using JPA
>> unless there is a compelling reason to do otherwise. I only mention
>> OJB as a plugin candidate that Jetspeed might use in the future,
>> not an important one that Wookie support natively.
>
> OK, that makes sense. JPA, JDO, EmpireDB etc are all in the same
> category, as relatively straight switches for HIbernate.
>
>> I dont have any experience with Thrift+Cayenne, but I'd be happy to
>> include that configuration/technology stack in any approach.
>
> Bryan can probably help there I imagine..?
>
>>
>> Let me know,
>>
>> Randy
>>
>> Scott Wilson wrote:
>>> On 11 May 2010, at 18:22, Randy Watler wrote:
>>>
>>>
>>>> Kris/All:
>>>>
>>>> Hello... I am currently starting to modify Wookie to use a JCR
>>>> backend for use in a CMS web site environment. I am also
>>>> interested in making the solutions pluggable along the way so
>>>> that other implementations can be used to suit the environment.
>>>> I am a committer on the Jetspeed project and there is interest
>>>> there as well, so using the native store there, (OJB), would be
>>>> ideal. Obviously, this thread has mentioned other candidates!
>>>>
>>>> How best can I help you guys here make this happen?
>>>>
>>>
>>> Hi Randy,
>>>
>>> The most pluggable we can be the better I reckon. So things like
>>> JCR, JPA and so on do have an advantage in that they allow
>>> multiple implementations. However if we can also make it possible
>>> to have a Thrift connection to Cayenne then that's good too!
>>>
>>> I put OJB on the candidate list, but when I looked at the I
>>> couldn't see much activity (last commit back in 2008) - though
>>> maybe thats just because its mature. What's your experience of
>>> OJB in Jetspeed?
>>>
>>> - Scott .
>>>> Randy
>>>>
>>>> Kris Popat wrote:
>>>>
>>>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>>>
>>>>>
>>>>>> Kris,
>>>>>>
>>>>>> When you mentioned building your own file-based solution it
>>>>>> made me think of the growing "no-SQL" movement. I wonder if
>>>>>> it might be useful to leverage yet again another Apache
>>>>>> project, Cassandra: http://cassandra.apache.org/
>>>>>>
>>>>>> For "very large-scale" systems (and likely much more
>>>>>> complicated), is Apache Hadoop: http://hadoop.apache.org/
>>>>>>
>>>>>> Probably most know about these, but they are examples of
>>>>>> key-based and graph-based storage systems, respectively...
>>>>>> Document-based approaches already exist too, so it may make
>>>>>> sense to leverage the work done by the CouchDB team:
>>>>>> http://couchdb.apache.org/
>>>>>>
>>>>>> Just thought I'd share that as the first two projects, and
>>>>>> Wookie, are currently the three up and coming Apache
>>>>>> projects my organization is tracking most closely. I'm not
>>>>>> sure who will win the "efficiency/lightweight data store
>>>>>> war", but in the end, an approach which offers options and
>>>>>> flexibility for datastore configuration will probably be
>>>>>> the nicest for the community, but, most difficult to
>>>>>> accomplish because of the differences between RDBMS and
>>>>>> Graph-based camps, perhaps Document-based might be a nice
>>>>>> middle-ground though?
>>>>>>
>>>>> Thanks for that, will add them to the list of possibilities
>>>>> on the wiki. These look very interesting. Best for us is to
>>>>> find something that slots in easily replacing the current db
>>>>> middleware that we are using taking issues of robustness,
>>>>> extensibility, load handling and licensing into
>>>>> consideration. Will be spending some time on this over the
>>>>> next few days tinkering and evaluating
>>>>>
>>>>>
>>>>>
>>>>>> Bryan
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Kris Popat
>>>>>> [mailto:kjpopat@googlemail.com] Sent: May 11, 2010 5:28 AM
>>>>>> To: wookie-dev@incubator.apache.org Subject: Re: important
>>>>>> todo: remove hibernate (was Re: Fwd: Several podling
>>>>>> reports still missing at
>>>>>> http://wiki.apache.org/incubator/May2010, due today)
>>>>>>
>>>>>>
>>>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>>>
>>>>>>
>>>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>>>
>>>>>>>>> I've updated the report here:
>>>>>>>>>
>>>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>>>
>>>>>>>> +1 to your report.
>>>>>>>>
>>>>>>>> A busy quarter.
>>>>>>>>
>>>>>>>> I'm largely silent at present due to spending all my
>>>>>>>> time on http://www.transfersummit.com (people should
>>>>>>>> come, it's a great conference).
>>>>>>>>
>>>>>>>> Once that's out of the way I want to really crack on
>>>>>>>> with getting rid of hibernate so we can get a release
>>>>>>>> out the door. In my opinion, we need a release to
>>>>>>>> really start building community.
>>>>>>>>
>>>>>>>> Of course, if someone wants to get cracking on that
>>>>>>>> before me I'll gladly start a branch for that work and
>>>>>>>> keep it aligned with trunk for you (asuuming you are
>>>>>>>> not already a committer).
>>>>>>>>
>>>>>>> Yes, that's pretty much the last hurdle.
>>>>>>>
>>>>>>> Kris, were you going to put together a list of candidates
>>>>>>> for replacing Hibernate on the wiki?
>>>>>>>
>>>>>> Yes I've looked through some options a couple of weeks ago,
>>>>>> will pick it up again and put some ideas up.
>>>>>>
>>>>>> It might be worth testing a file based solution that I've
>>>>>> been working on too. I'll put a patch up for people to
>>>>>> test in a few days time. Will need testing for robustness
>>>>>> and speed.
>>>>>>
>>>>>>
>>>>>>>> Ross
>>>>>>>>
>>>>> Kris
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
Re: important todo: remove hibernate
Posted by Ross Gardler <rg...@apache.org>.
On 11/05/2010 22:33, Copeland, Bryan wrote:
> Can't promise any brilliant code or anything, but I'll at least look
> into Cayenne and compare with what I already know about Hibernate,
> JPA and no-SQL tools so that I might be able to at least make a more
> reasonable recommendation, if not contribute some sample code at some
> point of how to connect Wookie to at least one of the no-SQL
> datastores...
Sounds like you will do a better job of it than I would. It would be
great to see some sample code to complement Randy;s proposed work in JPA
and JSR.
Great to have you folk on board.
Ross
>
> Bryan
>
>
>
> -----Original Message----- From: Scott Wilson
> [mailto:scott.bradley.wilson@gmail.com] Sent: May 11, 2010 3:04 PM
> To: wookie-dev@incubator.apache.org Subject: Re: important todo:
> remove hibernate
>
> On 11 May 2010, at 18:53, Randy Watler wrote:
>
>> Scott:
>>
>> I am willing to take on this project starting immediately if it can
>> help you guys and I would not be getting in the way of the ongoing
>> work of others. Like I said, I have to support JCR storage for
>> Wookie in any case ASAP.
>
> That sounds great to me - what do other committers think? I can
> imagine other implementations where a JCR connection is going to be
> useful (Sakai comes to mind, for example).
>
>> OJB is what Jetspeed uses internally... I would suggest using JPA
>> unless there is a compelling reason to do otherwise. I only mention
>> OJB as a plugin candidate that Jetspeed might use in the future,
>> not an important one that Wookie support natively.
>
> OK, that makes sense. JPA, JDO, EmpireDB etc are all in the same
> category, as relatively straight switches for HIbernate.
>
>> I dont have any experience with Thrift+Cayenne, but I'd be happy to
>> include that configuration/technology stack in any approach.
>
> Bryan can probably help there I imagine..?
>
>>
>> Let me know,
>>
>> Randy
>>
>> Scott Wilson wrote:
>>> On 11 May 2010, at 18:22, Randy Watler wrote:
>>>
>>>
>>>> Kris/All:
>>>>
>>>> Hello... I am currently starting to modify Wookie to use a JCR
>>>> backend for use in a CMS web site environment. I am also
>>>> interested in making the solutions pluggable along the way so
>>>> that other implementations can be used to suit the environment.
>>>> I am a committer on the Jetspeed project and there is interest
>>>> there as well, so using the native store there, (OJB), would be
>>>> ideal. Obviously, this thread has mentioned other candidates!
>>>>
>>>> How best can I help you guys here make this happen?
>>>>
>>>
>>> Hi Randy,
>>>
>>> The most pluggable we can be the better I reckon. So things like
>>> JCR, JPA and so on do have an advantage in that they allow
>>> multiple implementations. However if we can also make it possible
>>> to have a Thrift connection to Cayenne then that's good too!
>>>
>>> I put OJB on the candidate list, but when I looked at the I
>>> couldn't see much activity (last commit back in 2008) - though
>>> maybe thats just because its mature. What's your experience of
>>> OJB in Jetspeed?
>>>
>>> - Scott .
>>>> Randy
>>>>
>>>> Kris Popat wrote:
>>>>
>>>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>>>
>>>>>
>>>>>> Kris,
>>>>>>
>>>>>> When you mentioned building your own file-based solution it
>>>>>> made me think of the growing "no-SQL" movement. I wonder if
>>>>>> it might be useful to leverage yet again another Apache
>>>>>> project, Cassandra: http://cassandra.apache.org/
>>>>>>
>>>>>> For "very large-scale" systems (and likely much more
>>>>>> complicated), is Apache Hadoop: http://hadoop.apache.org/
>>>>>>
>>>>>> Probably most know about these, but they are examples of
>>>>>> key-based and graph-based storage systems, respectively...
>>>>>> Document-based approaches already exist too, so it may make
>>>>>> sense to leverage the work done by the CouchDB team:
>>>>>> http://couchdb.apache.org/
>>>>>>
>>>>>> Just thought I'd share that as the first two projects, and
>>>>>> Wookie, are currently the three up and coming Apache
>>>>>> projects my organization is tracking most closely. I'm not
>>>>>> sure who will win the "efficiency/lightweight data store
>>>>>> war", but in the end, an approach which offers options and
>>>>>> flexibility for datastore configuration will probably be
>>>>>> the nicest for the community, but, most difficult to
>>>>>> accomplish because of the differences between RDBMS and
>>>>>> Graph-based camps, perhaps Document-based might be a nice
>>>>>> middle-ground though?
>>>>>>
>>>>> Thanks for that, will add them to the list of possibilities
>>>>> on the wiki. These look very interesting. Best for us is to
>>>>> find something that slots in easily replacing the current db
>>>>> middleware that we are using taking issues of robustness,
>>>>> extensibility, load handling and licensing into
>>>>> consideration. Will be spending some time on this over the
>>>>> next few days tinkering and evaluating
>>>>>
>>>>>
>>>>>
>>>>>> Bryan
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Kris Popat
>>>>>> [mailto:kjpopat@googlemail.com] Sent: May 11, 2010 5:28 AM
>>>>>> To: wookie-dev@incubator.apache.org Subject: Re: important
>>>>>> todo: remove hibernate (was Re: Fwd: Several podling
>>>>>> reports still missing at
>>>>>> http://wiki.apache.org/incubator/May2010, due today)
>>>>>>
>>>>>>
>>>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>>>
>>>>>>
>>>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>>>
>>>>>>>>> I've updated the report here:
>>>>>>>>>
>>>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>>>
>>>>>>>> +1 to your report.
>>>>>>>>
>>>>>>>> A busy quarter.
>>>>>>>>
>>>>>>>> I'm largely silent at present due to spending all my
>>>>>>>> time on http://www.transfersummit.com (people should
>>>>>>>> come, it's a great conference).
>>>>>>>>
>>>>>>>> Once that's out of the way I want to really crack on
>>>>>>>> with getting rid of hibernate so we can get a release
>>>>>>>> out the door. In my opinion, we need a release to
>>>>>>>> really start building community.
>>>>>>>>
>>>>>>>> Of course, if someone wants to get cracking on that
>>>>>>>> before me I'll gladly start a branch for that work and
>>>>>>>> keep it aligned with trunk for you (asuuming you are
>>>>>>>> not already a committer).
>>>>>>>>
>>>>>>> Yes, that's pretty much the last hurdle.
>>>>>>>
>>>>>>> Kris, were you going to put together a list of candidates
>>>>>>> for replacing Hibernate on the wiki?
>>>>>>>
>>>>>> Yes I've looked through some options a couple of weeks ago,
>>>>>> will pick it up again and put some ideas up.
>>>>>>
>>>>>> It might be worth testing a file based solution that I've
>>>>>> been working on too. I'll put a patch up for people to
>>>>>> test in a few days time. Will need testing for robustness
>>>>>> and speed.
>>>>>>
>>>>>>
>>>>>>>> Ross
>>>>>>>>
>>>>> Kris
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
Re: important todo: remove hibernate
Posted by Randy Watler <wa...@wispertel.net>.
Scott/Paul,
Thanks guys!
Randy
Scott Wilson wrote:
> On 14 May 2010, at 12:17, Paul Sharples wrote:
>
>
>> On 14/05/2010 11:44, Scott Wilson wrote:
>>
>>> On 14 May 2010, at 11:35, Paul Sharples wrote:
>>>
>>>
>>>
>>>> On 14/05/2010 08:24, Scott Wilson wrote:
>>>>
>>>>
>>>>> On 14 May 2010, at 00:18, Randy Watler wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hey Gang,
>>>>>>
>>>>>> I noticed that SharedData and Participant are keyed back to the Widget using the GUID field. This is in contrast to the preponderance of the persistent data which is keyed to Widget via its object id. I assume there is no objection to unifying this for all Widget relationships and using the object id. Otherwise, let me know if the use of GUID for SharedData and Participant was by design and I missed something along the way. Thanks!
>>>>>>
>>>>>>
>>>>>>
>>>>> The "sibling" definition for shared data and participants uses the rule of "same widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we can guarantee the stability of the ID - I think keying on GUID is simply because this should always be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I don't think this should really be a problem, so keying on the ID should be fine.
>>>>>
>>>>> Unless Paul can think of a reason why we still need to do it this way?
>>>>>
>>>>>
>>>>>
>>>> Other than Scotts comments, I can't see any problem with using the id instead. However, as a point of note, an earlier version of wookie didn't have the GUID field in the shareddata table at least. I originally envisaged shareddata to be associated with widgetinstances, rather than an actual widget. Do we need to have either widgetid/guid in there at all? You can get both of those values from widgetinstance.getWidget().
>>>>
>>>>
>>> Wouldn't you then have to have multiple copies of the same data row in the table? After all a shareddata entry is shared by multiple instances.
>>>
>>>
>> shareddata is shared by multiple instances but accessed by each of those instances using the shareddatakey which should result on the operation being carried out on the same record. (or so I thought)
>>
>> widgetinstance1 has a shareddatakey of "mykey", but the userid is "fred". It adds a new shareddata tuple: dkey ="chatlog" (shareddatakey="mykey")
>> widgetinstance2 has a shareddatakey of "mykey", but the userid is "bob". It also wants to add a new shareddata tuple: dkey="chatlog", but should first check to see if there already exists an entry in shared data with the values dkey="chatlog" and shareddatakey="mykey". If its already there, then widgetinstance2 appends to that tuple.
>>
>> So each widgetinstance uses the dkey and shareddatakey to lookup the correct record. I guess shareddatakey & dkey in shareddata should be a compound/composite key.
>>
>> Its possible I'm getting confused now.
>>
>
> Looking in the code, there are only a couple of cases where shareddata.widgetguid are used:
>
> 1. In the Wave API, for collecting together all the shareddata instances related to a single instance to push a state update to that instance, e.g:
>
> for(SharedData data : SharedData.findSharedDataForInstance(widgetInstance)){
> state.put(data.getDkey(), data.getDvalue());
> }
> return state;
>
> 2. In the Clone() method of the REST API for cloning a state model
> 3. In the Destroy() method of the REST API for removing all references to a widget instance (hmm, not sure about that being correct...)
>
> You're correct that shareddatakey+dkey is the composite primary key for shareddata. Widgetguid is just a handy hook for some special queries, and could use either the id or guid.
>
>
>> Paul
>>
>>>
>>>
>>>>>
>>>>>
>>>>>> Randy
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>
>
Re: important todo: remove hibernate
Posted by Scott Wilson <sc...@gmail.com>.
On 14 May 2010, at 12:17, Paul Sharples wrote:
> On 14/05/2010 11:44, Scott Wilson wrote:
>> On 14 May 2010, at 11:35, Paul Sharples wrote:
>>
>>
>>> On 14/05/2010 08:24, Scott Wilson wrote:
>>>
>>>> On 14 May 2010, at 00:18, Randy Watler wrote:
>>>>
>>>>
>>>>
>>>>> Hey Gang,
>>>>>
>>>>> I noticed that SharedData and Participant are keyed back to the Widget using the GUID field. This is in contrast to the preponderance of the persistent data which is keyed to Widget via its object id. I assume there is no objection to unifying this for all Widget relationships and using the object id. Otherwise, let me know if the use of GUID for SharedData and Participant was by design and I missed something along the way. Thanks!
>>>>>
>>>>>
>>>> The "sibling" definition for shared data and participants uses the rule of "same widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we can guarantee the stability of the ID - I think keying on GUID is simply because this should always be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I don't think this should really be a problem, so keying on the ID should be fine.
>>>>
>>>> Unless Paul can think of a reason why we still need to do it this way?
>>>>
>>>>
>>> Other than Scotts comments, I can't see any problem with using the id instead. However, as a point of note, an earlier version of wookie didn't have the GUID field in the shareddata table at least. I originally envisaged shareddata to be associated with widgetinstances, rather than an actual widget. Do we need to have either widgetid/guid in there at all? You can get both of those values from widgetinstance.getWidget().
>>>
>> Wouldn't you then have to have multiple copies of the same data row in the table? After all a shareddata entry is shared by multiple instances.
>>
> shareddata is shared by multiple instances but accessed by each of those instances using the shareddatakey which should result on the operation being carried out on the same record. (or so I thought)
>
> widgetinstance1 has a shareddatakey of "mykey", but the userid is "fred". It adds a new shareddata tuple: dkey ="chatlog" (shareddatakey="mykey")
> widgetinstance2 has a shareddatakey of "mykey", but the userid is "bob". It also wants to add a new shareddata tuple: dkey="chatlog", but should first check to see if there already exists an entry in shared data with the values dkey="chatlog" and shareddatakey="mykey". If its already there, then widgetinstance2 appends to that tuple.
>
> So each widgetinstance uses the dkey and shareddatakey to lookup the correct record. I guess shareddatakey & dkey in shareddata should be a compound/composite key.
>
> Its possible I'm getting confused now.
Looking in the code, there are only a couple of cases where shareddata.widgetguid are used:
1. In the Wave API, for collecting together all the shareddata instances related to a single instance to push a state update to that instance, e.g:
for(SharedData data : SharedData.findSharedDataForInstance(widgetInstance)){
state.put(data.getDkey(), data.getDvalue());
}
return state;
2. In the Clone() method of the REST API for cloning a state model
3. In the Destroy() method of the REST API for removing all references to a widget instance (hmm, not sure about that being correct...)
You're correct that shareddatakey+dkey is the composite primary key for shareddata. Widgetguid is just a handy hook for some special queries, and could use either the id or guid.
>
> Paul
>>
>>>>
>>>>
>>>>> Randy
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: important todo: remove hibernate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 14/05/2010 11:44, Scott Wilson wrote:
> On 14 May 2010, at 11:35, Paul Sharples wrote:
>
>
>> On 14/05/2010 08:24, Scott Wilson wrote:
>>
>>> On 14 May 2010, at 00:18, Randy Watler wrote:
>>>
>>>
>>>
>>>> Hey Gang,
>>>>
>>>> I noticed that SharedData and Participant are keyed back to the Widget using the GUID field. This is in contrast to the preponderance of the persistent data which is keyed to Widget via its object id. I assume there is no objection to unifying this for all Widget relationships and using the object id. Otherwise, let me know if the use of GUID for SharedData and Participant was by design and I missed something along the way. Thanks!
>>>>
>>>>
>>> The "sibling" definition for shared data and participants uses the rule of "same widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we can guarantee the stability of the ID - I think keying on GUID is simply because this should always be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I don't think this should really be a problem, so keying on the ID should be fine.
>>>
>>> Unless Paul can think of a reason why we still need to do it this way?
>>>
>>>
>> Other than Scotts comments, I can't see any problem with using the id instead. However, as a point of note, an earlier version of wookie didn't have the GUID field in the shareddata table at least. I originally envisaged shareddata to be associated with widgetinstances, rather than an actual widget. Do we need to have either widgetid/guid in there at all? You can get both of those values from widgetinstance.getWidget().
>>
> Wouldn't you then have to have multiple copies of the same data row in the table? After all a shareddata entry is shared by multiple instances.
>
shareddata is shared by multiple instances but accessed by each of those
instances using the shareddatakey which should result on the operation
being carried out on the same record. (or so I thought)
widgetinstance1 has a shareddatakey of "mykey", but the userid is
"fred". It adds a new shareddata tuple: dkey ="chatlog"
(shareddatakey="mykey")
widgetinstance2 has a shareddatakey of "mykey", but the userid is
"bob". It also wants to add a new shareddata tuple: dkey="chatlog", but
should first check to see if there already exists an entry in shared
data with the values dkey="chatlog" and shareddatakey="mykey". If its
already there, then widgetinstance2 appends to that tuple.
So each widgetinstance uses the dkey and shareddatakey to lookup the
correct record. I guess shareddatakey & dkey in shareddata should be a
compound/composite key.
Its possible I'm getting confused now.
Paul
>
>>>
>>>
>>>> Randy
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: important todo: remove hibernate
Posted by Scott Wilson <sc...@gmail.com>.
On 14 May 2010, at 11:35, Paul Sharples wrote:
> On 14/05/2010 08:24, Scott Wilson wrote:
>> On 14 May 2010, at 00:18, Randy Watler wrote:
>>
>>
>>> Hey Gang,
>>>
>>> I noticed that SharedData and Participant are keyed back to the Widget using the GUID field. This is in contrast to the preponderance of the persistent data which is keyed to Widget via its object id. I assume there is no objection to unifying this for all Widget relationships and using the object id. Otherwise, let me know if the use of GUID for SharedData and Participant was by design and I missed something along the way. Thanks!
>>>
>> The "sibling" definition for shared data and participants uses the rule of "same widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we can guarantee the stability of the ID - I think keying on GUID is simply because this should always be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I don't think this should really be a problem, so keying on the ID should be fine.
>>
>> Unless Paul can think of a reason why we still need to do it this way?
>>
> Other than Scotts comments, I can't see any problem with using the id instead. However, as a point of note, an earlier version of wookie didn't have the GUID field in the shareddata table at least. I originally envisaged shareddata to be associated with widgetinstances, rather than an actual widget. Do we need to have either widgetid/guid in there at all? You can get both of those values from widgetinstance.getWidget().
Wouldn't you then have to have multiple copies of the same data row in the table? After all a shareddata entry is shared by multiple instances.
>>
>>> Randy
>>>
>>>
>>
>
Re: important todo: remove hibernate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 14/05/2010 08:24, Scott Wilson wrote:
> On 14 May 2010, at 00:18, Randy Watler wrote:
>
>
>> Hey Gang,
>>
>> I noticed that SharedData and Participant are keyed back to the Widget using the GUID field. This is in contrast to the preponderance of the persistent data which is keyed to Widget via its object id. I assume there is no objection to unifying this for all Widget relationships and using the object id. Otherwise, let me know if the use of GUID for SharedData and Participant was by design and I missed something along the way. Thanks!
>>
> The "sibling" definition for shared data and participants uses the rule of "same widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we can guarantee the stability of the ID - I think keying on GUID is simply because this should always be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I don't think this should really be a problem, so keying on the ID should be fine.
>
> Unless Paul can think of a reason why we still need to do it this way?
>
Other than Scotts comments, I can't see any problem with using the id
instead. However, as a point of note, an earlier version of wookie
didn't have the GUID field in the shareddata table at least. I
originally envisaged shareddata to be associated with widgetinstances,
rather than an actual widget. Do we need to have either widgetid/guid
in there at all? You can get both of those values from
widgetinstance.getWidget().
>
>> Randy
>>
>>
>
Re: important todo: remove hibernate
Posted by Scott Wilson <sc...@gmail.com>.
On 14 May 2010, at 00:18, Randy Watler wrote:
> Hey Gang,
>
> I noticed that SharedData and Participant are keyed back to the Widget using the GUID field. This is in contrast to the preponderance of the persistent data which is keyed to Widget via its object id. I assume there is no objection to unifying this for all Widget relationships and using the object id. Otherwise, let me know if the use of GUID for SharedData and Participant was by design and I missed something along the way. Thanks!
The "sibling" definition for shared data and participants uses the rule of "same widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we can guarantee the stability of the ID - I think keying on GUID is simply because this should always be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I don't think this should really be a problem, so keying on the ID should be fine.
Unless Paul can think of a reason why we still need to do it this way?
>
> Randy
>
Re: important todo: remove hibernate
Posted by Randy Watler <wa...@wispertel.net>.
Hey Gang,
I noticed that SharedData and Participant are keyed back to the Widget
using the GUID field. This is in contrast to the preponderance of the
persistent data which is keyed to Widget via its object id. I assume
there is no objection to unifying this for all Widget relationships and
using the object id. Otherwise, let me know if the use of GUID for
SharedData and Participant was by design and I missed something along
the way. Thanks!
Randy
Re: important todo: remove hibernate
Posted by Ross Gardler <rg...@apache.org>.
On 12/05/2010 17:36, Randy Watler wrote:
> Scott, Bryan, Kris, and Ross:
>
> I have been looking into existing Wookie persistent object
> implementation and how I might maintain the existing Active Record
> Pattern APIs. Thus far, it seems that there are basically two pluggable
> approaches to choose from:
>
> 1. Maintain the existing Active Record Pattern/classes and use hidden
> delegates for each object to support different persistence
> implementations, or
> 2. replace the existing classes with interfaces and a persistence
> component that encapsulates the implementations.
>
> The advantage of keeping the Active Record Pattern intact is that it
> maximally preserves the existing code base and designs, but in order to
> make it pluggable it seems to require shadow objects and the complexity
> that entails. Moving to a persistence component API with interfaces
> allows more flexibility in which to deliver the persistence mappings,
> but is obviously more intrusive.
>
> Any implementation preference, thoughts, or comments?
For me ease of maintenance and clear APIs is always the way to go in the
long term.
A little short term disruption for long term gain is always worth it.
Ross
Re: important todo: remove hibernate
Posted by Randy Watler <wa...@wispertel.net>.
Scott, Bryan, Kris, and Ross:
I have been looking into existing Wookie persistent object
implementation and how I might maintain the existing Active Record
Pattern APIs. Thus far, it seems that there are basically two pluggable
approaches to choose from:
1. Maintain the existing Active Record Pattern/classes and use hidden
delegates for each object to support different persistence
implementations, or
2. replace the existing classes with interfaces and a persistence
component that encapsulates the implementations.
The advantage of keeping the Active Record Pattern intact is that it
maximally preserves the existing code base and designs, but in order to
make it pluggable it seems to require shadow objects and the complexity
that entails. Moving to a persistence component API with interfaces
allows more flexibility in which to deliver the persistence mappings,
but is obviously more intrusive.
Any implementation preference, thoughts, or comments?
Thanks,
Randy
Re: important todo: remove hibernate
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2010, at 22:33, Copeland, Bryan wrote:
>>> I dont have any experience with Thrift+Cayenne, but I'd be happy to include that configuration/technology stack in any approach.
>
>> Bryan can probably help there I imagine..?
>
> In fact I have no experience with Cayenne. Of the projects listed so far, I'm most probably comfortable with Cassandra (twissandra project is an excellent crash-course in that btw: http://github.com/ericflo/twissandra)
D'oh I actually meant Cassandra!
> I've done projects which had their own database abstraction (one had to support Derby, MySQL, PostgreSQL, DB2, Oracle all at the same time with connection pooling). This was before tools like Cayenne were available... not to mention, a naiive approach using .properties files and generous switch statements to manage pools were sufficient for my purposes, but I'd hazard to guess not so much in an Apache community-quality full release.
>
> Can't promise any brilliant code or anything, but I'll at least look into Cayenne and compare with what I already know about Hibernate, JPA and no-SQL tools so that I might be able to at least make a more reasonable recommendation, if not contribute some sample code at some point of how to connect Wookie to at least one of the no-SQL datastores...
>
> Bryan
>
>
>
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: May 11, 2010 3:04 PM
> To: wookie-dev@incubator.apache.org
> Subject: Re: important todo: remove hibernate
>
> On 11 May 2010, at 18:53, Randy Watler wrote:
>
>> Scott:
>>
>> I am willing to take on this project starting immediately if it can help you guys and I would not be getting in the way of the ongoing work of others. Like I said, I have to support JCR storage for Wookie in any case ASAP.
>
> That sounds great to me - what do other committers think? I can imagine other implementations where a JCR connection is going to be useful (Sakai comes to mind, for example).
>
>> OJB is what Jetspeed uses internally... I would suggest using JPA unless there is a compelling reason to do otherwise. I only mention OJB as a plugin candidate that Jetspeed might use in the future, not an important one that Wookie support natively.
>
> OK, that makes sense. JPA, JDO, EmpireDB etc are all in the same category, as relatively straight switches for HIbernate.
>
>> I dont have any experience with Thrift+Cayenne, but I'd be happy to include that configuration/technology stack in any approach.
>
> Bryan can probably help there I imagine..?
>
>>
>> Let me know,
>>
>> Randy
>>
>> Scott Wilson wrote:
>>> On 11 May 2010, at 18:22, Randy Watler wrote:
>>>
>>>
>>>> Kris/All:
>>>>
>>>> Hello... I am currently starting to modify Wookie to use a JCR backend for use in a CMS web site environment. I am also interested in making the solutions pluggable along the way so that other implementations can be used to suit the environment. I am a committer on the Jetspeed project and there is interest there as well, so using the native store there, (OJB), would be ideal. Obviously, this thread has mentioned other candidates!
>>>>
>>>> How best can I help you guys here make this happen?
>>>>
>>>
>>> Hi Randy,
>>>
>>> The most pluggable we can be the better I reckon. So things like JCR, JPA and so on do have an advantage in that they allow multiple implementations. However if we can also make it possible to have a Thrift connection to Cayenne then that's good too!
>>>
>>> I put OJB on the candidate list, but when I looked at the I couldn't see much activity (last commit back in 2008) - though maybe thats just because its mature. What's your experience of OJB in Jetspeed?
>>>
>>> - Scott
>>> .
>>>> Randy
>>>>
>>>> Kris Popat wrote:
>>>>
>>>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>>>
>>>>>
>>>>>> Kris,
>>>>>>
>>>>>> When you mentioned building your own file-based solution it made me think of the growing "no-SQL" movement. I wonder if it might be useful to leverage yet again another Apache project, Cassandra:
>>>>>> http://cassandra.apache.org/
>>>>>>
>>>>>> For "very large-scale" systems (and likely much more complicated), is Apache Hadoop:
>>>>>> http://hadoop.apache.org/
>>>>>>
>>>>>> Probably most know about these, but they are examples of key-based and graph-based storage systems, respectively... Document-based approaches already exist too, so it may make sense to leverage the work done by the CouchDB team:
>>>>>> http://couchdb.apache.org/
>>>>>>
>>>>>> Just thought I'd share that as the first two projects, and Wookie, are currently the three up and coming Apache projects my organization is tracking most closely. I'm not sure who will win the "efficiency/lightweight data store war", but in the end, an approach which offers options and flexibility for datastore configuration will probably be the nicest for the community, but, most difficult to accomplish because of the differences between RDBMS and Graph-based camps, perhaps Document-based might be a nice middle-ground though?
>>>>>>
>>>>> Thanks for that, will add them to the list of possibilities on the wiki. These look very interesting. Best for us is to find something that slots in easily replacing the current db middleware that we are using taking issues of robustness, extensibility, load handling and licensing into consideration. Will be spending some time on this over the next few days tinkering and evaluating
>>>>>
>>>>>
>>>>>
>>>>>> Bryan
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Kris Popat [mailto:kjpopat@googlemail.com]
>>>>>> Sent: May 11, 2010 5:28 AM
>>>>>> To: wookie-dev@incubator.apache.org
>>>>>> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
>>>>>>
>>>>>>
>>>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>>>
>>>>>>
>>>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>>>
>>>>>>>>> I've updated the report here:
>>>>>>>>>
>>>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>>>
>>>>>>>> +1 to your report.
>>>>>>>>
>>>>>>>> A busy quarter.
>>>>>>>>
>>>>>>>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>>>>>>>> (people should come, it's a great conference).
>>>>>>>>
>>>>>>>> Once that's out of the way I want to really crack on with getting
>>>>>>>> rid of hibernate so we can get a release out the door. In my
>>>>>>>> opinion, we need a release to really start building community.
>>>>>>>>
>>>>>>>> Of course, if someone wants to get cracking on that before me I'll
>>>>>>>> gladly start a branch for that work and keep it aligned with trunk
>>>>>>>> for you (asuuming you are not already a committer).
>>>>>>>>
>>>>>>> Yes, that's pretty much the last hurdle.
>>>>>>>
>>>>>>> Kris, were you going to put together a list of candidates for
>>>>>>> replacing Hibernate on the wiki?
>>>>>>>
>>>>>> Yes I've looked through some options a couple of weeks ago, will pick
>>>>>> it up again and put some ideas up.
>>>>>>
>>>>>> It might be worth testing a file based solution that I've been working
>>>>>> on too. I'll put a patch up for people to test in a few days time.
>>>>>> Will need testing for robustness and speed.
>>>>>>
>>>>>>
>>>>>>>> Ross
>>>>>>>>
>>>>> Kris
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
RE: important todo: remove hibernate
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
>> I dont have any experience with Thrift+Cayenne, but I'd be happy to include that configuration/technology stack in any approach.
> Bryan can probably help there I imagine..?
In fact I have no experience with Cayenne. Of the projects listed so far, I'm most probably comfortable with Cassandra (twissandra project is an excellent crash-course in that btw: http://github.com/ericflo/twissandra)
I've done projects which had their own database abstraction (one had to support Derby, MySQL, PostgreSQL, DB2, Oracle all at the same time with connection pooling). This was before tools like Cayenne were available... not to mention, a naiive approach using .properties files and generous switch statements to manage pools were sufficient for my purposes, but I'd hazard to guess not so much in an Apache community-quality full release.
Can't promise any brilliant code or anything, but I'll at least look into Cayenne and compare with what I already know about Hibernate, JPA and no-SQL tools so that I might be able to at least make a more reasonable recommendation, if not contribute some sample code at some point of how to connect Wookie to at least one of the no-SQL datastores...
Bryan
-----Original Message-----
From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
Sent: May 11, 2010 3:04 PM
To: wookie-dev@incubator.apache.org
Subject: Re: important todo: remove hibernate
On 11 May 2010, at 18:53, Randy Watler wrote:
> Scott:
>
> I am willing to take on this project starting immediately if it can help you guys and I would not be getting in the way of the ongoing work of others. Like I said, I have to support JCR storage for Wookie in any case ASAP.
That sounds great to me - what do other committers think? I can imagine other implementations where a JCR connection is going to be useful (Sakai comes to mind, for example).
> OJB is what Jetspeed uses internally... I would suggest using JPA unless there is a compelling reason to do otherwise. I only mention OJB as a plugin candidate that Jetspeed might use in the future, not an important one that Wookie support natively.
OK, that makes sense. JPA, JDO, EmpireDB etc are all in the same category, as relatively straight switches for HIbernate.
> I dont have any experience with Thrift+Cayenne, but I'd be happy to include that configuration/technology stack in any approach.
Bryan can probably help there I imagine..?
>
> Let me know,
>
> Randy
>
> Scott Wilson wrote:
>> On 11 May 2010, at 18:22, Randy Watler wrote:
>>
>>
>>> Kris/All:
>>>
>>> Hello... I am currently starting to modify Wookie to use a JCR backend for use in a CMS web site environment. I am also interested in making the solutions pluggable along the way so that other implementations can be used to suit the environment. I am a committer on the Jetspeed project and there is interest there as well, so using the native store there, (OJB), would be ideal. Obviously, this thread has mentioned other candidates!
>>>
>>> How best can I help you guys here make this happen?
>>>
>>
>> Hi Randy,
>>
>> The most pluggable we can be the better I reckon. So things like JCR, JPA and so on do have an advantage in that they allow multiple implementations. However if we can also make it possible to have a Thrift connection to Cayenne then that's good too!
>>
>> I put OJB on the candidate list, but when I looked at the I couldn't see much activity (last commit back in 2008) - though maybe thats just because its mature. What's your experience of OJB in Jetspeed?
>>
>> - Scott
>> .
>>> Randy
>>>
>>> Kris Popat wrote:
>>>
>>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>>
>>>>
>>>>> Kris,
>>>>>
>>>>> When you mentioned building your own file-based solution it made me think of the growing "no-SQL" movement. I wonder if it might be useful to leverage yet again another Apache project, Cassandra:
>>>>> http://cassandra.apache.org/
>>>>>
>>>>> For "very large-scale" systems (and likely much more complicated), is Apache Hadoop:
>>>>> http://hadoop.apache.org/
>>>>>
>>>>> Probably most know about these, but they are examples of key-based and graph-based storage systems, respectively... Document-based approaches already exist too, so it may make sense to leverage the work done by the CouchDB team:
>>>>> http://couchdb.apache.org/
>>>>>
>>>>> Just thought I'd share that as the first two projects, and Wookie, are currently the three up and coming Apache projects my organization is tracking most closely. I'm not sure who will win the "efficiency/lightweight data store war", but in the end, an approach which offers options and flexibility for datastore configuration will probably be the nicest for the community, but, most difficult to accomplish because of the differences between RDBMS and Graph-based camps, perhaps Document-based might be a nice middle-ground though?
>>>>>
>>>> Thanks for that, will add them to the list of possibilities on the wiki. These look very interesting. Best for us is to find something that slots in easily replacing the current db middleware that we are using taking issues of robustness, extensibility, load handling and licensing into consideration. Will be spending some time on this over the next few days tinkering and evaluating
>>>>
>>>>
>>>>
>>>>> Bryan
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Kris Popat [mailto:kjpopat@googlemail.com]
>>>>> Sent: May 11, 2010 5:28 AM
>>>>> To: wookie-dev@incubator.apache.org
>>>>> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
>>>>>
>>>>>
>>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>>
>>>>>
>>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>>
>>>>>>
>>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>>
>>>>>>>> I've updated the report here:
>>>>>>>>
>>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>>
>>>>>>> +1 to your report.
>>>>>>>
>>>>>>> A busy quarter.
>>>>>>>
>>>>>>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>>>>>>> (people should come, it's a great conference).
>>>>>>>
>>>>>>> Once that's out of the way I want to really crack on with getting
>>>>>>> rid of hibernate so we can get a release out the door. In my
>>>>>>> opinion, we need a release to really start building community.
>>>>>>>
>>>>>>> Of course, if someone wants to get cracking on that before me I'll
>>>>>>> gladly start a branch for that work and keep it aligned with trunk
>>>>>>> for you (asuuming you are not already a committer).
>>>>>>>
>>>>>> Yes, that's pretty much the last hurdle.
>>>>>>
>>>>>> Kris, were you going to put together a list of candidates for
>>>>>> replacing Hibernate on the wiki?
>>>>>>
>>>>> Yes I've looked through some options a couple of weeks ago, will pick
>>>>> it up again and put some ideas up.
>>>>>
>>>>> It might be worth testing a file based solution that I've been working
>>>>> on too. I'll put a patch up for people to test in a few days time.
>>>>> Will need testing for robustness and speed.
>>>>>
>>>>>
>>>>>>> Ross
>>>>>>>
>>>> Kris
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: important todo: remove hibernate
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2010, at 18:53, Randy Watler wrote:
> Scott:
>
> I am willing to take on this project starting immediately if it can help you guys and I would not be getting in the way of the ongoing work of others. Like I said, I have to support JCR storage for Wookie in any case ASAP.
That sounds great to me - what do other committers think? I can imagine other implementations where a JCR connection is going to be useful (Sakai comes to mind, for example).
> OJB is what Jetspeed uses internally... I would suggest using JPA unless there is a compelling reason to do otherwise. I only mention OJB as a plugin candidate that Jetspeed might use in the future, not an important one that Wookie support natively.
OK, that makes sense. JPA, JDO, EmpireDB etc are all in the same category, as relatively straight switches for HIbernate.
> I dont have any experience with Thrift+Cayenne, but I'd be happy to include that configuration/technology stack in any approach.
Bryan can probably help there I imagine..?
>
> Let me know,
>
> Randy
>
> Scott Wilson wrote:
>> On 11 May 2010, at 18:22, Randy Watler wrote:
>>
>>
>>> Kris/All:
>>>
>>> Hello... I am currently starting to modify Wookie to use a JCR backend for use in a CMS web site environment. I am also interested in making the solutions pluggable along the way so that other implementations can be used to suit the environment. I am a committer on the Jetspeed project and there is interest there as well, so using the native store there, (OJB), would be ideal. Obviously, this thread has mentioned other candidates!
>>>
>>> How best can I help you guys here make this happen?
>>>
>>
>> Hi Randy,
>>
>> The most pluggable we can be the better I reckon. So things like JCR, JPA and so on do have an advantage in that they allow multiple implementations. However if we can also make it possible to have a Thrift connection to Cayenne then that's good too!
>>
>> I put OJB on the candidate list, but when I looked at the I couldn't see much activity (last commit back in 2008) - though maybe thats just because its mature. What's your experience of OJB in Jetspeed?
>>
>> - Scott
>> .
>>> Randy
>>>
>>> Kris Popat wrote:
>>>
>>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>>
>>>>
>>>>> Kris,
>>>>>
>>>>> When you mentioned building your own file-based solution it made me think of the growing "no-SQL" movement. I wonder if it might be useful to leverage yet again another Apache project, Cassandra:
>>>>> http://cassandra.apache.org/
>>>>>
>>>>> For "very large-scale" systems (and likely much more complicated), is Apache Hadoop:
>>>>> http://hadoop.apache.org/
>>>>>
>>>>> Probably most know about these, but they are examples of key-based and graph-based storage systems, respectively... Document-based approaches already exist too, so it may make sense to leverage the work done by the CouchDB team:
>>>>> http://couchdb.apache.org/
>>>>>
>>>>> Just thought I'd share that as the first two projects, and Wookie, are currently the three up and coming Apache projects my organization is tracking most closely. I'm not sure who will win the "efficiency/lightweight data store war", but in the end, an approach which offers options and flexibility for datastore configuration will probably be the nicest for the community, but, most difficult to accomplish because of the differences between RDBMS and Graph-based camps, perhaps Document-based might be a nice middle-ground though?
>>>>>
>>>> Thanks for that, will add them to the list of possibilities on the wiki. These look very interesting. Best for us is to find something that slots in easily replacing the current db middleware that we are using taking issues of robustness, extensibility, load handling and licensing into consideration. Will be spending some time on this over the next few days tinkering and evaluating
>>>>
>>>>
>>>>
>>>>> Bryan
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Kris Popat [mailto:kjpopat@googlemail.com]
>>>>> Sent: May 11, 2010 5:28 AM
>>>>> To: wookie-dev@incubator.apache.org
>>>>> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
>>>>>
>>>>>
>>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>>
>>>>>
>>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>>
>>>>>>
>>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>>
>>>>>>>> I've updated the report here:
>>>>>>>>
>>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>>
>>>>>>> +1 to your report.
>>>>>>>
>>>>>>> A busy quarter.
>>>>>>>
>>>>>>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>>>>>>> (people should come, it's a great conference).
>>>>>>>
>>>>>>> Once that's out of the way I want to really crack on with getting
>>>>>>> rid of hibernate so we can get a release out the door. In my
>>>>>>> opinion, we need a release to really start building community.
>>>>>>>
>>>>>>> Of course, if someone wants to get cracking on that before me I'll
>>>>>>> gladly start a branch for that work and keep it aligned with trunk
>>>>>>> for you (asuuming you are not already a committer).
>>>>>>>
>>>>>> Yes, that's pretty much the last hurdle.
>>>>>>
>>>>>> Kris, were you going to put together a list of candidates for
>>>>>> replacing Hibernate on the wiki?
>>>>>>
>>>>> Yes I've looked through some options a couple of weeks ago, will pick
>>>>> it up again and put some ideas up.
>>>>>
>>>>> It might be worth testing a file based solution that I've been working
>>>>> on too. I'll put a patch up for people to test in a few days time.
>>>>> Will need testing for robustness and speed.
>>>>>
>>>>>
>>>>>>> Ross
>>>>>>>
>>>> Kris
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: important todo: remove hibernate
Posted by Randy Watler <wa...@wispertel.net>.
Scott:
I am willing to take on this project starting immediately if it can help
you guys and I would not be getting in the way of the ongoing work of
others. Like I said, I have to support JCR storage for Wookie in any
case ASAP.
OJB is what Jetspeed uses internally... I would suggest using JPA unless
there is a compelling reason to do otherwise. I only mention OJB as a
plugin candidate that Jetspeed might use in the future, not an important
one that Wookie support natively.
I dont have any experience with Thrift+Cayenne, but I'd be happy to
include that configuration/technology stack in any approach.
Let me know,
Randy
Scott Wilson wrote:
> On 11 May 2010, at 18:22, Randy Watler wrote:
>
>
>> Kris/All:
>>
>> Hello... I am currently starting to modify Wookie to use a JCR backend for use in a CMS web site environment. I am also interested in making the solutions pluggable along the way so that other implementations can be used to suit the environment. I am a committer on the Jetspeed project and there is interest there as well, so using the native store there, (OJB), would be ideal. Obviously, this thread has mentioned other candidates!
>>
>> How best can I help you guys here make this happen?
>>
>
> Hi Randy,
>
> The most pluggable we can be the better I reckon. So things like JCR, JPA and so on do have an advantage in that they allow multiple implementations. However if we can also make it possible to have a Thrift connection to Cayenne then that's good too!
>
> I put OJB on the candidate list, but when I looked at the I couldn't see much activity (last commit back in 2008) - though maybe thats just because its mature. What's your experience of OJB in Jetspeed?
>
> - Scott
> .
>
>> Randy
>>
>> Kris Popat wrote:
>>
>>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>>
>>>
>>>> Kris,
>>>>
>>>> When you mentioned building your own file-based solution it made me think of the growing "no-SQL" movement. I wonder if it might be useful to leverage yet again another Apache project, Cassandra:
>>>> http://cassandra.apache.org/
>>>>
>>>> For "very large-scale" systems (and likely much more complicated), is Apache Hadoop:
>>>> http://hadoop.apache.org/
>>>>
>>>> Probably most know about these, but they are examples of key-based and graph-based storage systems, respectively... Document-based approaches already exist too, so it may make sense to leverage the work done by the CouchDB team:
>>>> http://couchdb.apache.org/
>>>>
>>>> Just thought I'd share that as the first two projects, and Wookie, are currently the three up and coming Apache projects my organization is tracking most closely. I'm not sure who will win the "efficiency/lightweight data store war", but in the end, an approach which offers options and flexibility for datastore configuration will probably be the nicest for the community, but, most difficult to accomplish because of the differences between RDBMS and Graph-based camps, perhaps Document-based might be a nice middle-ground though?
>>>>
>>> Thanks for that, will add them to the list of possibilities on the wiki. These look very interesting. Best for us is to find something that slots in easily replacing the current db middleware that we are using taking issues of robustness, extensibility, load handling and licensing into consideration. Will be spending some time on this over the next few days tinkering and evaluating
>>>
>>>
>>>
>>>> Bryan
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Kris Popat [mailto:kjpopat@googlemail.com]
>>>> Sent: May 11, 2010 5:28 AM
>>>> To: wookie-dev@incubator.apache.org
>>>> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
>>>>
>>>>
>>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>>
>>>>
>>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>>
>>>>>
>>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>>
>>>>>>> I've updated the report here:
>>>>>>>
>>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>>>
>>>>>> +1 to your report.
>>>>>>
>>>>>> A busy quarter.
>>>>>>
>>>>>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>>>>>> (people should come, it's a great conference).
>>>>>>
>>>>>> Once that's out of the way I want to really crack on with getting
>>>>>> rid of hibernate so we can get a release out the door. In my
>>>>>> opinion, we need a release to really start building community.
>>>>>>
>>>>>> Of course, if someone wants to get cracking on that before me I'll
>>>>>> gladly start a branch for that work and keep it aligned with trunk
>>>>>> for you (asuuming you are not already a committer).
>>>>>>
>>>>> Yes, that's pretty much the last hurdle.
>>>>>
>>>>> Kris, were you going to put together a list of candidates for
>>>>> replacing Hibernate on the wiki?
>>>>>
>>>> Yes I've looked through some options a couple of weeks ago, will pick
>>>> it up again and put some ideas up.
>>>>
>>>> It might be worth testing a file based solution that I've been working
>>>> on too. I'll put a patch up for people to test in a few days time.
>>>> Will need testing for robustness and speed.
>>>>
>>>>
>>>>>> Ross
>>>>>>
>>> Kris
>>>
>>>
>>>
>
>
>
Re: important todo: remove hibernate
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2010, at 18:22, Randy Watler wrote:
> Kris/All:
>
> Hello... I am currently starting to modify Wookie to use a JCR backend for use in a CMS web site environment. I am also interested in making the solutions pluggable along the way so that other implementations can be used to suit the environment. I am a committer on the Jetspeed project and there is interest there as well, so using the native store there, (OJB), would be ideal. Obviously, this thread has mentioned other candidates!
>
> How best can I help you guys here make this happen?
Hi Randy,
The most pluggable we can be the better I reckon. So things like JCR, JPA and so on do have an advantage in that they allow multiple implementations. However if we can also make it possible to have a Thrift connection to Cayenne then that's good too!
I put OJB on the candidate list, but when I looked at the I couldn't see much activity (last commit back in 2008) - though maybe thats just because its mature. What's your experience of OJB in Jetspeed?
- Scott
.
>
> Randy
>
> Kris Popat wrote:
>>
>> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>>
>>> Kris,
>>>
>>> When you mentioned building your own file-based solution it made me think of the growing "no-SQL" movement. I wonder if it might be useful to leverage yet again another Apache project, Cassandra:
>>> http://cassandra.apache.org/
>>>
>>> For "very large-scale" systems (and likely much more complicated), is Apache Hadoop:
>>> http://hadoop.apache.org/
>>>
>>> Probably most know about these, but they are examples of key-based and graph-based storage systems, respectively... Document-based approaches already exist too, so it may make sense to leverage the work done by the CouchDB team:
>>> http://couchdb.apache.org/
>>>
>>> Just thought I'd share that as the first two projects, and Wookie, are currently the three up and coming Apache projects my organization is tracking most closely. I'm not sure who will win the "efficiency/lightweight data store war", but in the end, an approach which offers options and flexibility for datastore configuration will probably be the nicest for the community, but, most difficult to accomplish because of the differences between RDBMS and Graph-based camps, perhaps Document-based might be a nice middle-ground though?
>>
>>
>> Thanks for that, will add them to the list of possibilities on the wiki. These look very interesting. Best for us is to find something that slots in easily replacing the current db middleware that we are using taking issues of robustness, extensibility, load handling and licensing into consideration. Will be spending some time on this over the next few days tinkering and evaluating
>>
>>
>>>
>>> Bryan
>>>
>>>
>>> -----Original Message-----
>>> From: Kris Popat [mailto:kjpopat@googlemail.com]
>>> Sent: May 11, 2010 5:28 AM
>>> To: wookie-dev@incubator.apache.org
>>> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
>>>
>>>
>>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>>
>>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>>
>>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>>> I've updated the report here:
>>>>>>
>>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>>
>>>>> +1 to your report.
>>>>>
>>>>> A busy quarter.
>>>>>
>>>>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>>>>> (people should come, it's a great conference).
>>>>>
>>>>> Once that's out of the way I want to really crack on with getting
>>>>> rid of hibernate so we can get a release out the door. In my
>>>>> opinion, we need a release to really start building community.
>>>>>
>>>>> Of course, if someone wants to get cracking on that before me I'll
>>>>> gladly start a branch for that work and keep it aligned with trunk
>>>>> for you (asuuming you are not already a committer).
>>>>
>>>> Yes, that's pretty much the last hurdle.
>>>>
>>>> Kris, were you going to put together a list of candidates for
>>>> replacing Hibernate on the wiki?
>>>
>>> Yes I've looked through some options a couple of weeks ago, will pick
>>> it up again and put some ideas up.
>>>
>>> It might be worth testing a file based solution that I've been working
>>> on too. I'll put a patch up for people to test in a few days time.
>>> Will need testing for robustness and speed.
>>>
>>>>
>>>>>
>>>>> Ross
>>>>
>>>
>>
>> Kris
>>
>>
>
Re: important todo: remove hibernate (was Re: Fwd: Several podling
reports still missing at http://wiki.apache.org/incubator/May2010, due today)
Posted by Randy Watler <wa...@wispertel.net>.
Kris/All:
Hello... I am currently starting to modify Wookie to use a JCR backend
for use in a CMS web site environment. I am also interested in making
the solutions pluggable along the way so that other implementations can
be used to suit the environment. I am a committer on the Jetspeed
project and there is interest there as well, so using the native store
there, (OJB), would be ideal. Obviously, this thread has mentioned other
candidates!
How best can I help you guys here make this happen?
Randy
Kris Popat wrote:
>
> On 11 May 2010, at 15:07, Copeland, Bryan wrote:
>
>> Kris,
>>
>> When you mentioned building your own file-based solution it made me
>> think of the growing "no-SQL" movement. I wonder if it might be
>> useful to leverage yet again another Apache project, Cassandra:
>> http://cassandra.apache.org/
>>
>> For "very large-scale" systems (and likely much more complicated), is
>> Apache Hadoop:
>> http://hadoop.apache.org/
>>
>> Probably most know about these, but they are examples of key-based
>> and graph-based storage systems, respectively... Document-based
>> approaches already exist too, so it may make sense to leverage the
>> work done by the CouchDB team:
>> http://couchdb.apache.org/
>>
>> Just thought I'd share that as the first two projects, and Wookie,
>> are currently the three up and coming Apache projects my organization
>> is tracking most closely. I'm not sure who will win the
>> "efficiency/lightweight data store war", but in the end, an approach
>> which offers options and flexibility for datastore configuration will
>> probably be the nicest for the community, but, most difficult to
>> accomplish because of the differences between RDBMS and Graph-based
>> camps, perhaps Document-based might be a nice middle-ground though?
>
>
> Thanks for that, will add them to the list of possibilities on the
> wiki. These look very interesting. Best for us is to find something
> that slots in easily replacing the current db middleware that we are
> using taking issues of robustness, extensibility, load handling and
> licensing into consideration. Will be spending some time on this over
> the next few days tinkering and evaluating
>
>
>>
>> Bryan
>>
>>
>> -----Original Message-----
>> From: Kris Popat [mailto:kjpopat@googlemail.com]
>> Sent: May 11, 2010 5:28 AM
>> To: wookie-dev@incubator.apache.org
>> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several
>> podling reports still missing at
>> http://wiki.apache.org/incubator/May2010, due today)
>>
>>
>> On 11 May 2010, at 09:21, Scott Wilson wrote:
>>
>>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>>
>>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>>> I've updated the report here:
>>>>>
>>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>>
>>>> +1 to your report.
>>>>
>>>> A busy quarter.
>>>>
>>>> I'm largely silent at present due to spending all my time on
>>>> http://www.transfersummit.com
>>>> (people should come, it's a great conference).
>>>>
>>>> Once that's out of the way I want to really crack on with getting
>>>> rid of hibernate so we can get a release out the door. In my
>>>> opinion, we need a release to really start building community.
>>>>
>>>> Of course, if someone wants to get cracking on that before me I'll
>>>> gladly start a branch for that work and keep it aligned with trunk
>>>> for you (asuuming you are not already a committer).
>>>
>>> Yes, that's pretty much the last hurdle.
>>>
>>> Kris, were you going to put together a list of candidates for
>>> replacing Hibernate on the wiki?
>>
>> Yes I've looked through some options a couple of weeks ago, will pick
>> it up again and put some ideas up.
>>
>> It might be worth testing a file based solution that I've been working
>> on too. I'll put a patch up for people to test in a few days time.
>> Will need testing for robustness and speed.
>>
>>>
>>>>
>>>> Ross
>>>
>>
>
> Kris
>
>
Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
Posted by Kris Popat <kj...@googlemail.com>.
On 11 May 2010, at 15:07, Copeland, Bryan wrote:
> Kris,
>
> When you mentioned building your own file-based solution it made me
> think of the growing "no-SQL" movement. I wonder if it might be
> useful to leverage yet again another Apache project, Cassandra:
> http://cassandra.apache.org/
>
> For "very large-scale" systems (and likely much more complicated),
> is Apache Hadoop:
> http://hadoop.apache.org/
>
> Probably most know about these, but they are examples of key-based
> and graph-based storage systems, respectively... Document-based
> approaches already exist too, so it may make sense to leverage the
> work done by the CouchDB team:
> http://couchdb.apache.org/
>
> Just thought I'd share that as the first two projects, and Wookie,
> are currently the three up and coming Apache projects my
> organization is tracking most closely. I'm not sure who will win the
> "efficiency/lightweight data store war", but in the end, an approach
> which offers options and flexibility for datastore configuration
> will probably be the nicest for the community, but, most difficult
> to accomplish because of the differences between RDBMS and Graph-
> based camps, perhaps Document-based might be a nice middle-ground
> though?
Thanks for that, will add them to the list of possibilities on the
wiki. These look very interesting. Best for us is to find something
that slots in easily replacing the current db middleware that we are
using taking issues of robustness, extensibility, load handling and
licensing into consideration. Will be spending some time on this over
the next few days tinkering and evaluating
>
> Bryan
>
>
> -----Original Message-----
> From: Kris Popat [mailto:kjpopat@googlemail.com]
> Sent: May 11, 2010 5:28 AM
> To: wookie-dev@incubator.apache.org
> Subject: Re: important todo: remove hibernate (was Re: Fwd: Several
> podling reports still missing at http://wiki.apache.org/incubator/May2010
> , due today)
>
>
> On 11 May 2010, at 09:21, Scott Wilson wrote:
>
>> On 11 May 2010, at 09:16, Ross Gardler wrote:
>>
>>> On 11/05/2010 09:05, Scott Wilson wrote:
>>>> I've updated the report here:
>>>>
>>>> http://wiki.apache.org/incubator/May2010#Wookie
>>>
>>> +1 to your report.
>>>
>>> A busy quarter.
>>>
>>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>>> (people should come, it's a great conference).
>>>
>>> Once that's out of the way I want to really crack on with getting
>>> rid of hibernate so we can get a release out the door. In my
>>> opinion, we need a release to really start building community.
>>>
>>> Of course, if someone wants to get cracking on that before me I'll
>>> gladly start a branch for that work and keep it aligned with trunk
>>> for you (asuuming you are not already a committer).
>>
>> Yes, that's pretty much the last hurdle.
>>
>> Kris, were you going to put together a list of candidates for
>> replacing Hibernate on the wiki?
>
> Yes I've looked through some options a couple of weeks ago, will pick
> it up again and put some ideas up.
>
> It might be worth testing a file based solution that I've been working
> on too. I'll put a patch up for people to test in a few days time.
> Will need testing for robustness and speed.
>
>>
>>>
>>> Ross
>>
>
Kris
RE: important todo: remove hibernate (was Re: Fwd: Several podling
reports still missing at http://wiki.apache.org/incubator/May2010, due
today)
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
Kris,
When you mentioned building your own file-based solution it made me think of the growing "no-SQL" movement. I wonder if it might be useful to leverage yet again another Apache project, Cassandra:
http://cassandra.apache.org/
For "very large-scale" systems (and likely much more complicated), is Apache Hadoop:
http://hadoop.apache.org/
Probably most know about these, but they are examples of key-based and graph-based storage systems, respectively... Document-based approaches already exist too, so it may make sense to leverage the work done by the CouchDB team:
http://couchdb.apache.org/
Just thought I'd share that as the first two projects, and Wookie, are currently the three up and coming Apache projects my organization is tracking most closely. I'm not sure who will win the "efficiency/lightweight data store war", but in the end, an approach which offers options and flexibility for datastore configuration will probably be the nicest for the community, but, most difficult to accomplish because of the differences between RDBMS and Graph-based camps, perhaps Document-based might be a nice middle-ground though?
Bryan
-----Original Message-----
From: Kris Popat [mailto:kjpopat@googlemail.com]
Sent: May 11, 2010 5:28 AM
To: wookie-dev@incubator.apache.org
Subject: Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
On 11 May 2010, at 09:21, Scott Wilson wrote:
> On 11 May 2010, at 09:16, Ross Gardler wrote:
>
>> On 11/05/2010 09:05, Scott Wilson wrote:
>>> I've updated the report here:
>>>
>>> http://wiki.apache.org/incubator/May2010#Wookie
>>
>> +1 to your report.
>>
>> A busy quarter.
>>
>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>> (people should come, it's a great conference).
>>
>> Once that's out of the way I want to really crack on with getting
>> rid of hibernate so we can get a release out the door. In my
>> opinion, we need a release to really start building community.
>>
>> Of course, if someone wants to get cracking on that before me I'll
>> gladly start a branch for that work and keep it aligned with trunk
>> for you (asuuming you are not already a committer).
>
> Yes, that's pretty much the last hurdle.
>
> Kris, were you going to put together a list of candidates for
> replacing Hibernate on the wiki?
Yes I've looked through some options a couple of weeks ago, will pick
it up again and put some ideas up.
It might be worth testing a file based solution that I've been working
on too. I'll put a patch up for people to test in a few days time.
Will need testing for robustness and speed.
>
>>
>> Ross
>
Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
Posted by Kris Popat <kj...@googlemail.com>.
On 11 May 2010, at 09:21, Scott Wilson wrote:
> On 11 May 2010, at 09:16, Ross Gardler wrote:
>
>> On 11/05/2010 09:05, Scott Wilson wrote:
>>> I've updated the report here:
>>>
>>> http://wiki.apache.org/incubator/May2010#Wookie
>>
>> +1 to your report.
>>
>> A busy quarter.
>>
>> I'm largely silent at present due to spending all my time on http://www.transfersummit.com
>> (people should come, it's a great conference).
>>
>> Once that's out of the way I want to really crack on with getting
>> rid of hibernate so we can get a release out the door. In my
>> opinion, we need a release to really start building community.
>>
>> Of course, if someone wants to get cracking on that before me I'll
>> gladly start a branch for that work and keep it aligned with trunk
>> for you (asuuming you are not already a committer).
>
> Yes, that's pretty much the last hurdle.
>
> Kris, were you going to put together a list of candidates for
> replacing Hibernate on the wiki?
Yes I've looked through some options a couple of weeks ago, will pick
it up again and put some ideas up.
It might be worth testing a file based solution that I've been working
on too. I'll put a patch up for people to test in a few days time.
Will need testing for robustness and speed.
>
>>
>> Ross
>
Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2010, at 09:16, Ross Gardler wrote:
> On 11/05/2010 09:05, Scott Wilson wrote:
>> I've updated the report here:
>>
>> http://wiki.apache.org/incubator/May2010#Wookie
>
> +1 to your report.
>
> A busy quarter.
>
> I'm largely silent at present due to spending all my time on http://www.transfersummit.com (people should come, it's a great conference).
>
> Once that's out of the way I want to really crack on with getting rid of hibernate so we can get a release out the door. In my opinion, we need a release to really start building community.
>
> Of course, if someone wants to get cracking on that before me I'll gladly start a branch for that work and keep it aligned with trunk for you (asuuming you are not already a committer).
Yes, that's pretty much the last hurdle.
Kris, were you going to put together a list of candidates for replacing Hibernate on the wiki?
>
> Ross
Re: important todo: remove hibernate (was Re: Fwd: Several podling reports still missing at http://wiki.apache.org/incubator/May2010, due today)
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2010, at 09:16, Ross Gardler wrote:
> On 11/05/2010 09:05, Scott Wilson wrote:
>> I've updated the report here:
>>
>> http://wiki.apache.org/incubator/May2010#Wookie
>
> +1 to your report.
>
> A busy quarter.
>
> I'm largely silent at present due to spending all my time on http://www.transfersummit.com (people should come, it's a great conference).
>
> Once that's out of the way I want to really crack on with getting rid of hibernate so we can get a release out the door. In my opinion, we need a release to really start building community.
>
> Of course, if someone wants to get cracking on that before me I'll gladly start a branch for that work and keep it aligned with trunk for you (asuuming you are not already a committer).
Here's a placeholder wiki page for comparing the options to replace Hibernate:
http://incubator.apache.org/wookie/persistence.html
>
> Ross
important todo: remove hibernate (was Re: Fwd: Several podling reports
still missing at http://wiki.apache.org/incubator/May2010, due today)
Posted by Ross Gardler <rg...@apache.org>.
On 11/05/2010 09:05, Scott Wilson wrote:
> I've updated the report here:
>
> http://wiki.apache.org/incubator/May2010#Wookie
+1 to your report.
A busy quarter.
I'm largely silent at present due to spending all my time on
http://www.transfersummit.com (people should come, it's a great conference).
Once that's out of the way I want to really crack on with getting rid of
hibernate so we can get a release out the door. In my opinion, we need a
release to really start building community.
Of course, if someone wants to get cracking on that before me I'll
gladly start a branch for that work and keep it aligned with trunk for
you (asuuming you are not already a committer).
Ross