SDG: How to remove linkage between Domain Object and NodeBacked?

[stomat06]

Hey friends,

when loading a node out of NEO4Js graph database into our java domain object, there is a linkage between this object and the underlying NodeBacked object.
This linkage causes some limitations (for examle it is not possible to serialize the java object that is linked to the NodeBacked).

So back to the question: How can I remove this linkage between Domain Object and NodeBacked during runtime? Do i have to change the source code of Spring Data Graph 1.1.0?

Thanks for your help!

Best regards,

stomat06

[MichaelHunger]

Right now this is not possible and intended as the Node is used to access the data of your entity (it is not copied but read-through).
So for serializiation the way to go is to create a domain-level usecase-specific class that takes the data your other side needs and you copy it from your NodeEntity.

We are currently working on a second mapping strategy that uses the mapping abstractions of spring-data-commons and will not have a required backing-node after detachment (just a @GraphId).

[stomat06]

Thanks for your reply!

Do you have an idea by when serializtion is possible for NodeEntities?
Copying the data to another domain class level will cause to much effort. We currently have to decide if we will use SDG in our project.

[MichaelHunger]

Do you have to serialize just the entity or its outgoing/incoming relationships too?

If you can change the SDG source code, you might try the following

(if I find time, I can also look into it).

have a NodeBacked.detach() method in the Aspect that copies the data from the node (just properties, not relationships) and then calls setPersistentState(null)
(if there is a graphid field it should also set the node/rel-id there).

Cheers

Michael

[stomat06]

We want to serialize the entity with relationships (e.g. a Product with a Set of Subproducts).

We tried to set up a web service (JAX-WS), an EJB, tested java serialization and JSON: Same result for all --> Null-Values were created.

Do you think detaching node entities will be possible for the next milestone/release?

[MichaelHunger]

I will try to get it in. Could you have a look at XStream which can also serialize to JSON?

The problem with whole subgraph serialization is that you have to define bounds. I would not like to have JPA/Hibernate like fetch-annotations.
But we would rather propose a way where you create domain objects that represent your Product with Subproducts (only containing properties and relationships that you want to serialize) and then use:

UseCaseSpecificProduct useCaseSpecificProduct = product.projectTo(UseCaseSpecificProduct.class).de tach()
serialize(useCaseSpecificProduct)

[stomat06]

XStream creates xml-Strings with null-values too (when using NodeEntities).

How a UseCaseSpecificProduct could look like (so that projectTo is possible)?

@NodeEntity
public class Product{

@Indexed
long id;

@Indexed(fulltext = true, indexName = "productNameIndex")
String name;

@RelatedTo(type = "HAS_SUBPRODUCT", elementClass = Product.class)
private Set<Product> subproducts;

//and so on + getter, setter ...
}

public class UseCaseSpecificProduct{

//???

}



UseCaseSpecificProduct useCaseSpecificProduct = product.projectTo(UseCaseSpecificProduct.class).de tach() //this method must be implemented in SDG source?
serialize(useCaseSpecificProduct)

[MichaelHunger]

It just has to be a self contained subgraph, i.e. no outgoing Relationships to other parts of the Graphdb. So by copying all properties and following all outgoing relationships you effectively create a copy of the restricted subgraph which then could be serialized.

If the UseCaseSpecificProduct is not really specific to a use-case (i.e. limited number of properties and relationships of the original Product needed) then you could use inheritance to add additional properties and relationships for the normal Product.

LimitedProduct (use for serialization)
|
^
|
Product (adds additional properties and more outgoing relationships to this subgraph)

HTH

Michael

[ractive]

We are currently working on a second mapping strategy that uses the mapping abstractions of spring-data-commons and will not have a required backing-node after detachment (just a @GraphId).

This sounds very interesting also for our project. Are there already plans when such a feature could be available?

[MichaelHunger]

I'm still not sure what version of the "detachment strategy" to choose, see my mail to the neo4j users list.

The new SDN 2.0 is available at http://github.com/springsource/spring-data-neo4j

I'll write a mail/post about it today.

Michael