programmatic creation of relation

[aklemp]

I would like to use the create-methods in class Store to programmatically create a relation between two nodes. Let's take the relation DEPENDS_ON as example. It defines a relation between two artifacts (in the sense of Maven artifact). The following code tries to create a relation between two packages.

Package a = store.find(PackageDescriptor.class, "foo.bar");
Package b = store.find(PackageDescriptor.class, "foo.baz");
store.create(a, DependsOnDescriptor.class, b);

I get the following error.

com.buschmais.xo.api.XOException: Cannot resolve entity type containing a relation of type 'DependsOnDescriptor'.

From a graph point-of-view a relation is somewhat general purpose. In this example, many things might depend on other things.

I see three possible solutions, all of which have some drawbacks.

• execute a Cypher query (no refactoring support because it is all in a String)
• extend the incoming/outgoing descriptors used in a relation descriptor (might make no sense, a package is no Maven artifact)
• create another DependsOnDescriptor with different incoming/outgoing descriptors (a lot of code)

Is there any other way? Would it be useful to introduce some more abstraction? E.g. introduce a DependsOnIncomingDescriptor and DependsOnOutgoingDescriptor that can be used in Maven artifacts, packages and anything else.

[DirkMahler]

If it's only about a relation without properties then it's just necessary to add a relation property to the package descriptor:

public interface PackageDescriptor extends PackageMemberDescriptor, DirectoryDescriptor, FileContainerDescriptor {

  @Relation("DEPENDS_ON")
  List<PackageDescriptor> getDependencies();

}

and use it as follows:

dependentPackage.getDependencies().add(dependencyPackage);

The mechanism you're trying to use is for typed relations which may define properties. In this case mapping requires more information, see http://buschmais.github.io/extended-objects/doc/0.4.5/neo4j/#_typed_relations_with_properties

[DirkMahler]

Two questions:

• the package dependencies are calculated, i.e. must be aggregated during scan, may be a bit difficult due to the plugin structure.
• we should think about making this configurable, i.e. people are already asking to reduce level of detail while scanning for faster performance (e.g. only class relations like inheritance, dependencies but no field or method information.).

[aklemp]

While my question was of generic nature, I'm currently in the scope of integration tests. I didn't want to change the existing scanners. Thank you for the hints.

Nevertheless, configurable scanner detail configuration sounds like a nice feature. :-)

[obfischer]

Closing old ticket.