incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: Mappings - components and spread objects
Date Thu, 12 Jan 2006 10:01:10 GMT
Hi!

As I said this will be a multi-episode email, cause so far my research
is limitted.
Please see my comments inlined.

On 1/12/06, Christophe Lombart <christophe.lombart@gmail.com> wrote:
> Hi Alex,
>
> I'm also interesting by this kind of features. Here are my comments.
> On 1/12/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> > Hi!
> >
> > I've started thinking about possible extension of the current
> > supported mapping strategies. The directions I am investigating right
> > now are including:
> > - component mapping
>
> ok what about the following issue :
> http://issues.apache.org/jira/browse/GRFT-54.
>

Looks interesting. Must think of it. At a first glance, the approach I
am envisioning is to allow registration of custom node type
persisters. So that when an object with a corresponding such node type
is met during the object graph persistence we can delegate to its own
persister. Sure for, some special node types we can provide out of the
box persister. (as in your example: nt:file).

> > - relations
> Can you give more info. What kind of relations ? Are you speaking
> about object associations ?
>

Usually in objectual world we can talk about object associations:
one-to-one, one-to-many, many-to-one, many-to-many, unidirectional
associations, bidirectional associations. That's what will be here.

> > - inheritance
>
> ... and interface. It should be nice to make query based on interface
> and of course ancestor class.
>

Interface and ancestor classes are part of the inheritance, so yes I
hope to address these soon.

>
> > - spreaded
>
> Can you give more info ?

What I called spreaded objects is a concept that would mean persist an
object in various places (as opposed to persist an object to this
subtree nodes). Still I need to figure out if such a scenario makes
any sense. Furthermore, this is something that is last on my list, so
...

./alex
--
.w( the_mindstorm )p.

> >
> > So far (and indeed the easiest one) are the component mappings: they
> > allow mapping the properties of a child object to the properties of
> > the current working node. In the JCR world, a very good example of
> > this are the mixins. Introducing a mixin to a node may add a set of
> > properties that the user can manipulate with the help of a single
> > entity.
> > Such an entity doesn't have any restrictions upon it (no path
> > required, as it doesn't live by itself, no limitation in children,
> > anything).
> >
> > Please let me know what do you think about this.
> >
> > In the future episodes I will try to address the remaining areas.
> >
> > cheers,
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
>
>
> --
> Best regards,
>
> Christophe
>

Mime
View raw message