Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <46B8AE59.7030206@cognitiongroup.biz>
Date: Tue, 07 Aug 2007 10:39:37 -0700
From: Richard Schilling <rschilling@cognitiongroup.biz>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: jdo-dev@db.apache.org
Subject: Re: greetings and question about data stores
References: <46AF6F9F.6030309@cognitiongroup.biz>
 <012901c7d39d$4e409510$eac1bf30$@org> <46AFB67E.1040201@cognitiongroup.biz>
 <C00C01AA-F9B5-42C0-A8BC-EE36F5B7717C@SUN.com>
 <46B417A5.9030200@cognitiongroup.biz>
 <F2EB567B-3169-46CA-893C-F549305CD9CD@SUN.com>
 <46B4BB77.2090105@cognitiongroup.biz>
 <9DCAC8D5-1162-41B7-8A34-3550CB5ACEFE@SUN.com>
 <46B528FD.6080700@cognitiongroup.biz>
 <5F460DB5-B413-4FF8-BF41-F304FC32D331@SUN.com>
In-Reply-To: <5F460DB5-B413-4FF8-BF41-F304FC32D331@SUN.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Look forward to writing for the Wiki.  I'll go ahead and pull out my 
reference material so we can have some time-proven data store texts to 
work off of.  That will get us started.

Cheers!

Richard Schilling

Craig L Russell wrote:
> Sounds like there's room here for a good discussion, since JDO is the 
> only standard datastore-agnostic API that might exploit something like 
> MUMPS.
> 
> I'll set up a wiki where we can continue the dialog.
> 
> Craig
> 
> On Aug 4, 2007, at 6:33 PM, Richard Schilling wrote:
> 
>> I think an upgrade for FOStore is definitely feasible, but it should 
>> be redesigned.  There's no reason I can think of why a robust b-tree 
>> type implementation could not be managed.  The Berkeley DB sets are 
>> O.K., but they typically work well for small data sets.  Where we have 
>> large data sets, performance I think is pretty degraded.
>>
>> Having said that, I think there's a lot to be learned from an old, but 
>> very quick and very robust MUMPS data store.  It's underlying 
>> structure is essentially a b-tree, and works very well.  We could take 
>> a similar design approach.
>>
>> Richard Schilling
>>
>>
>> Craig L Russell wrote:
>>> Hi Richard,
>>> If you're interested in the non-RDBMS side of JDO, I've had for a 
>>> long time an interest in upgrading the FOStore piece to use a more 
>>> modern key/value store like a modern version of Berkeley DB.
>>> The sticking point for many of the non-RDBMS stores in the public 
>>> domain is the lack of query capability. And much of this is due to 
>>> the lack of schema for the values. In MDR, the key is 
>>> not-quite-opaque. You can see this in the special treatment of keys 
>>> in the FOStore key-generation. We'd have liked to use a simple long 
>>> as a key but MDR doesn't support them. And the value is truly opaque. 
>>> In FOStore we simply "serialize" the objects for storage replacing 
>>> objects with true FOStore object references.
>>> Anyway, if you're interested in upgrading FOStore to use a better 
>>> store than MDR, perhaps we can start a wiki to discuss this.
>>> Best,
>>> Craig
>>> On Aug 4, 2007, at 10:46 AM, Richard Schilling wrote:
>>>> Looking some more this morning, I also found the source code 
>>>> repository for netbeans b-tree implementation:
>>>>
>>>> http://mdr.netbeans.org/source/browse/mdr/src/org/netbeans/mdr/persistence/btreeimpl/?only_with_tag=release60_m4 
>>>>
>>>>
>>>>
>>>> And lo and behold, I also found an old CORBA module I didn't know 
>>>> existed.  This is going to get interesting.... :-)
>>>>
>>>> Richard
>>>>
>>>>
>>>> Craig L Russell wrote:
>>>>> Hi Richard,
>>>>> Sorry about that. The FOStore implementation had just a bit of 
>>>>> documentation which I've tried to locate for you but can't seem to 
>>>>> find just now. When I find it I'll post it on the JDO site and put 
>>>>> a link here.
>>>>> Craig
>>>>> On Aug 3, 2007, at 11:07 PM, Richard Schilling wrote:
>>>>>> Here is the posting I had way back in March of 2006, which didn't 
>>>>>> get much response - if any at all:
>>>>>>
>>>>>> http://www.webservertalk.com/archive383-2006-3-1437593.html
>>>>>>
>>>>>> Never did find out the answers to these questions, but this 
>>>>>> explains what I'm up to.
>>>>>>
>>>>>> After just looking, I find this on the netbeans site:
>>>>>>
>>>>>> http://mdr.netbeans.org/architecture.html#persistence
>>>>>>
>>>>>> This explains MDR, the use of b-tree (which the JDO reference 
>>>>>> implementation uses) in much more detail than I saw in the past.
>>>>>>
>>>>>> FYI.
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> Richard Schilling
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Craig L Russell wrote:
>>>>>>> Hi Richard,
>>>>>>> The fostore project at Apache JDO is an implementation that you 
>>>>>>> could study for insights as to how the various components 
>>>>>>> interact. There's a separation of an abstract StoreManager 
>>>>>>> responsible for storing data to a specific datastore, a 
>>>>>>> StateManager responsible for managing the state of individual 
>>>>>>> instances, and a PersistenceManager whose API is pretty much 
>>>>>>> defined in the JDO specification.
>>>>>>> Regards,
>>>>>>> Craig
>>>>>>> On Jul 31, 2007, at 3:23 PM, Richard Schilling wrote:
>>>>>>>> I did realize that the JDO API and the model in the apache code 
>>>>>>>> was just the implementation of the spec.  What I'm after is to 
>>>>>>>> make sure I understand what parts of the API (which interfaces) 
>>>>>>>> are used by a specific implementation to cause classes to be 
>>>>>>>> committed to the data store.  It looks like the transactions 
>>>>>>>> defined in the spec serve this purpose, but there's so much 
>>>>>>>> information I can't be sure.
>>>>>>>>
>>>>>>>> Thanks ... still getting my head around the JDO spec - I've even 
>>>>>>>> read the JDO book which I have.
>>>>>>>>
>>>>>>>> Cheers.
>>>>>>>> Richard
>>>>>>>>
>>>>>>>>
>>>>>>>> Matthew T. Adams wrote:
>>>>>>>>> Hi Richard,
>>>>>>>>> Apache JDO is the home of the JDO API (the interface & class 
>>>>>>>>> files of the
>>>>>>>>> specification) & TCK (the code that tests whether a JDO 
>>>>>>>>> implementation is
>>>>>>>>> compliant with the specification); none of the code here 
>>>>>>>>> actually writes to
>>>>>>>>> a database*.  The reference implementation for JDO 2.0 is JPOX
>>>>>>>>> (www.jpox.org) -- it is an implementation of the JDO 2.0 API.  
>>>>>>>>> There are
>>>>>>>>> also many other implementations of JDO out there.
>>>>>>>>> HTH,
>>>>>>>>> Matthew
>>>>>>>>> *:  There is a legacy reference implementation called FOStore 
>>>>>>>>> (pronounced
>>>>>>>>> like "foster") that was used as the JDO 1.0, but I don't think 
>>>>>>>>> that's used
>>>>>>>>> much anymore.  Others can comment on that.
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Richard Schilling [mailto:rschilling@cognitiongroup.biz] 
>>>>>>>>> Sent: Tuesday, July 31, 2007 10:22 AM
>>>>>>>>> To: jdo-dev@db.apache.org
>>>>>>>>> Subject: greetings and question about data stores
>>>>>>>>> Greetings.  This is my first post to the list.
>>>>>>>>> I would like to know about the code base itself.  There is not 
>>>>>>>>> any documentation that discusses the structure of the code 
>>>>>>>>> itself and how the software interacts with the data store.
>>>>>>>>> Can any one tell me what source code files actually contain the 
>>>>>>>>> code that writes to the data store?
>>>>>>>>> Thanks!
>>>>>>>>> Richard Schilling
>>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System 
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>