So what I've achieved so far is this:
@NodeEntity
public class Group {
private String name;
public String getName() {return name;}
public void setName(String name) {this.name = name;}
}
@NodeEntity
public class Named {
private String name;
public String getName() {return name;}
}
within the test:
Group group = new Group();
group.setName("developers");
Named named = (Named)group.projectTo(Named.class);
assertEquals("named.name","developers", named.getName());
assertEquals("nameds node name property","developers",
named.getUnderlyingState().getProperty("name"));
Which is nice, as Named and Group have no inheritance relation to each other
but just happen to have the same fields. Kind of duck typing :)
And you can also see that Named currently has no means to modify the property,
so this is just a readonly projection, not needing transactions to read this
and also not for the projection.
Cheers
Michael
Am 20.01.2011 um 07:45 schrieb Peter Neubauer:
> In some way,
> something similar is happening already in Neo4j Spatial. There is the
> domain dataset that e.g. could be created using the JRuby or Spring
> Data bindings, using the one-node-per-object approach. For the
> exposure of Polygons, Layers, LinesStrings and Points onto a GIS view,
> there are the GeometryEncoders/Decoders that tell how to fish out the
> information our of the graph via traversals, so that I see them as a
> projection, backing a class with an arbitrary amount of traversal and
> subgraphs.
>
> Being able to extend the projection model to include these "projected"
> use cases would make for a very cool generic mapping layer, I guess it
> could even do a decent work mapping different approaches onto the dame
> graph (like serving a JRuby binding and at the same time being
> compliant with Spring Data and some higher order mappings like Spatial
> constructs).
>
> Very cool.
>
> Cheers,
>
> /peter neubauer
>
> GTalk: neubauer.peter
> Skype peter.neubauer
> Phone +46 704 106975
> LinkedIn http://www.linkedin.com/in/neubauer
> Twitter http://twitter.com/peterneubauer
>
> http://www.neo4j.org - Your high performance graph database.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>
>
>
> On Thu, Jan 20, 2011 at 12:49 AM, Michael Hunger
> <[email protected]> wrote:
>> It was you David, who asked for the stricter checking against the type
>> hierarchy stored in the graph :)
>>
>> It does imply (right now) one node per class but not one class per node. As
>> this one node gives the instance its identity. It is also very similar to the
>> Qi4j state mixins where the id was the only fixed thing around.
>>
>> But the thought that we started with the cross-store could apply here as
>> well, as long we have an id (and perhaps an id-store-mapping) we can also
>> have multiple stores contributing to the
>> current projection.
>>
>> Cheers
>>
>> Michael
>>
>>
>> Am 19.01.2011 um 19:50 schrieb David Montag:
>>
>>> Hi,
>>>
>>> I think that's a good idea. It makes good use of the schema-free nature of
>>> the graph database, and also decouples the data from the interpretation of
>>> the data. I'm not sure it has to be two different modes. Maybe you just use
>>> one "projection" of the data if that's all you need. Or you use multiple.
>>>
>>> Does this still imply one node per class (projection)? Are you aiming to
>>> change that too?
>>>
>>> David
>>>
>>> On Wed, Jan 19, 2011 at 3:40 AM, Michael Hunger <
>>> [email protected]> wrote:
>>>
>>>> Today Andreas Kollegger and I had an interesting discussion about the
>>>> prevalence of class based mapping of entities to a graph store.
>>>>
>>>> One of the strengths of a graph store is that you don't need a strict
>>>> schema for your data and you can use lots of different projections to work
>>>> with it.
>>>>
>>>> Spring Data Graph currently focuses on a single projection of a node to an
>>>> entity instance (1:1) that traditional ORMs focused on.
>>>>
>>>> But we could do more. We can project the node to many different classes, as
>>>> long as the properties that are part of the class are there, we can
>>>> sensibly
>>>> work with the node.
>>>> Even if the projection class is not part of the type hierarchy that was
>>>> originally used to create and populate the node it can be used to access
>>>> it.
>>>>
>>>> That makes room for some interesting things like:
>>>> * new domain concepts can be used on top of existing data
>>>> * get rid of inheritance hierarchies
>>>> * traverse over a lot of nodes that support some basic properties that form
>>>> a concept (e.g. Person) using that simple concept during the traversal and
>>>> from there project those nodes to more concrete concepts as needed (e.g.
>>>> Employee, Customer)
>>>> * data/schema evolution / versioning
>>>>
>>>> We can run DATAGRAPH in a strict mode (not default) where it checks that
>>>> the node requested always fit to the domain class specified (according to
>>>> the type hierarchy stored in the graph). But we can (and should promote)
>>>> running it in a more loosely
>>>> coupled way where this free projection is possible.
>>>>
>>>> I would like to introduce a <T> T NodeBacked.projectTo(Class<T>) method to
>>>> the aspect so that this projection is easily available.
>>>>
>>>> Looking for feedback on that.
>>>>
>>>> Cheers
>>>>
>>>> Michael
>>>> _______________________________________________
>>>> Neo4j mailing list
>>>> [email protected]
>>>> https://lists.neo4j.org/mailman/listinfo/user
>>>>
>>>
>>>
>>>
>>> --
>>> David Montag
>>> Neo Technology, www.neotechnology.com
>>> Cell: 650.556.4411
>>> [email protected]
>>> _______________________________________________
>>> Neo4j mailing list
>>> [email protected]
>>> https://lists.neo4j.org/mailman/listinfo/user
>>
>> _______________________________________________
>> spring-neo mailing list
>> [email protected]
>> https://lists.springsource.com/listmanager/listinfo/spring-neo
>>
> _______________________________________________
> Neo4j mailing list
> [email protected]
> https://lists.neo4j.org/mailman/listinfo/user
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
