Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Subject: Re: RC5 or 1.0 ?
From: Josh Morris <josh.morris@unitt.org>
To: OJB Developers List <ojb-dev@db.apache.org>
In-Reply-To: 
 <34611.10.0.0.5.1065525844.squirrel@ags01.agsoftware.dnsalias.com>
References: 
	 <D7387C1AA470D51199E300508BBB4155023000EE@f94000r4.essen.karstadt.de>
	 <34611.10.0.0.5.1065525844.squirrel@ags01.agsoftware.dnsalias.com>
Content-Type: text/plain
Message-Id: <1065546273.1860.34.camel@jmorrislx.unitt.org>
Mime-Version: 1.0
Date: 07 Oct 2003 13:04:33 -0400
Content-Transfer-Encoding: 7bit

I think a 1.0 would be great!

However:
1) Oracle 9i should be considered a critical bug. It is unfortunate
(sometimes even sill) that LOBs are becoming as heavily used as they
are, but I don't think a mainstream O/R package can afford to ignore
their usage. I will look at this this week and attempt a patch (already
have one working in 0.9.7).
2) Serialization of Proxies - I have modified the proxy handling to
allow the user to specifiy an alternate subject materialization
mechanism to facilitate distributed (non-EJB, way to much overhead)
systems (i.e. systems where the client does not have OJB). It involves
the two simple changes listed below (I am happy to submit this) that
have little to no impact on the existing codebase (just moved some
methods around, no real change to logic)
	- Use a simple factory for identities to limit imports
	- VirtualProxy & alternate CollectionProxy now use a singleton
	SubjectMaterializerHandler (who uses the implementation 	specified in
config, defaults to current 	behaviour/implementation) to call into the
broker.
Some OJB classes (5 I believe) will still need to be on the classpath.
It would be nice to get this in the codebase so I don't have to continue
to maintain the changes. However, this effort did bring up a few
interesting points, which can generally be summed up as: Keeping the
proxies and references as ignorant of the api as possible so as to allow
an intelligent, and pluggable (kudos guys, it is so pluggable),
framework to handle any real operations (delegate
resolution/materialization) behaviours to configurable handlers.
------------------------------
a) The removal of the Query from the collection proxy (possibly use a
collection specific identity that can be used to buid a query if its
ever used. This will help to allow collection proxies to be easily
transported from one running vm to another.
b) ManageableCollection is broker aware (has methods acting on broker),
is this necessary since it maintains reference to the PBKey and there
are other ways now to resolve the broker?
------------------------------
I may not understand the intended direction or the full implications
these as I am not using the ODMG api. I am also perfectly happy to drop
the issue entirely if need be, I am quite pleased with OJB as a product
and can continue to maintain whatever changes are necessary. I am also
happy to put my time where my mouth is. If you need actual
implementations to demonstrate more fully what it is I am trying to say
(not always the best with communication), or "...just to shut up and
give us a patch we can look at...", I am happy to provide either.

Josh Morris
--
...the package said, "...requires Windows 2000 or better"...so I
installed Gentoo Linux ;)


On Tue, 2003-10-07 at 07:24, Antonio Gallardo wrote:
> Hi:
> 
> If there are not critical bugs, a version 1.0 would be fine.
> 
> Antonio Gallardo.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org