jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wolfgang Gehner" <wgeh...@infonoia.com>
Subject Re: Jackrabbit DBPersistenceManager
Date Thu, 25 Nov 2004 11:39:19 GMT
Summary of our discussion inline...

----- Original Message ----- 
From: "David Nuescheler" <david.nuescheler@gmail.com>
To: <jackrabbit-dev@incubator.apache.org>
Sent: Thursday, November 18, 2004 12:51 PM
Subject: Re: Jackrabbit DBPersistenceManager

> hi wolfgang,
> thanks a lot for contributing jdbc pm (persistence manager).
> after taking a first look at the code that you submitted
> personally i would like to have at least the
> following questions answered or issues resolved before
> i personally could vote +1 on the contribution. i am
> convinced that all of those issues/questions can be
> easily fixed/answered:
> -------
> first of all there seems an administrational issue
> that as far as i understand with respect to the
> fact that the contribution is a seperable contribution,
> we would need a CLA on file from you. for a patch
> this would not be necessary (please anybody correct me
> if i am wrong)

No problem, we can do that; when we do a patch (see below) that may not
be necessary.

> ---
> what is the benefit of the additional abstraction using
> dao, especially since the generic (abstract) datamodel
> is mandated by the implementation of the pm, shouldn't
> repository and jsr-170 provide such abstraction already?
> personally, i would probably favour a more direct
> access to the db.

We agreed that in most ways, (Persistent)Node already "is" a
DAO. So we don't propose to add an additional abstraction.

> ---
> should the empty class "MyHashmap" be removed or renamed?
> as far as i understand it may be useful for future
> extensibility however the classname doesn't inspire a
> clear intention ;) ?

We agreed to rename to a better name (Row?, MappedItem? we have to think).
We might show the extension options of the use of this class (use any bean
or possibly even PersistentNodeState instead of extensions of HashMap) in a
comment somewhere.

> ---
> since you submitted a 15mb package of the entire modified
> svn tree we have problems finding out what and why
> exactly was added / modified (do you think it would be
> possible to just send us a zip of your additions?)

We agreed that we will do a patch as you request.

> ---
> what is the thought behind creating a dom to pass
> arguments from one java method to another? was this
> just a quick hack or is that a pattern?

We just created an Element, not a full DOM, and only to reuse your method
which uses an Element. There is no real justification, we can pass the
params as HashMap no sweat.

> ----
> to me it looks like your pm does not support multivalue
> properties, references or binary values (am i wrong?).
> what concerns me about that is that those are important
> functional pieces of a repository

We agreed that we would attempt to add these features once you provide the
corresponding unit tests, that way the tests wouldn't have to be written
You know that blob support can be very database-specific, and datatype use
can vary from application to application (may keep html in longvarchars, but
multi-mb pdf's in datatype blob as supported by each database platform.
IBatis uses
interceptors to allow plugging different blob handlings.

> we are currently having internal discussion if we
> should commit that as an example on how we see
> an implementation of a jdbc pm that is very
> lightweight, fast and simple. obviously it requires
> a very abstract generic datamodel in the rdbms
> too...

DBPersistence layer should be flexible to allow legacy data models, and
tweaking of model (as to blob handling, user rights storage, "flatness" of
node properties storage etc.) to be useful in multiple environments and

> ----
> generally, i believe that the earlier proposed
> changes to the pm api, with respect to allow a
> pm to operate in a transactional
> fashion, as you suggested, will have quite
> a big impact. so i think it maybe still be
> worth waiting a little bit, until the pm api
> has "settled again" ;)

You said you would spend the next week or couple of weeks redesigning the
Persistence manager api etc.
and the result is likely to support transactional multi-row
update/delete/insert among other things. We will be pleased to
provide feedback on that, and then as a next step would do an implementation
that could be committed.

> -------
> this is probably not a complete list of
> questions/comments but it could be a
> starting point.
> another question that i have for the entire
> jackrabbit-dev-community:
> since it seems like a number of people started to
> implement jackrabbit pms and other
> extensions that maybe are not finished, should we
> create a section of the svn tree dedicated to
> experimental code in general? some sort of sandbox
> or proposals. experiences from other projects?
> additionally, since everybody received wolfgangs
> contribution, i would like to encourage everybody
> to use it and share their experiences.
> regards,
> david

Best regards,


View raw message