Create Edge via Java API triggers null pointer exception

[Fritz Gerald]

Hey everyone,

being new to OrientDB (using 2.0.5) I am testing it and it is not unlikely that I am the problem. Sorry for that!

1. Due to some requirements I need to create a simple edge without using the OrientVertex "addEdge" method.
   
2. I call the default OrientEdge constructor (new OrientEdge()) => therefore variable rawElement is null.
3. Now calling setProperty triggers convertToDocument method (due to the null rawElement in line 345) which gives a null pointer exception due to the unset vertices (line 450)

Simple code:

val t1= new OrientEdge()
t1.setProperty("x","test") => Causes null pointer exception

There is no way to provide the vertices latter on, the graph you can provide using the attach method. Is there an error in my thinking? Why do you provide any constructor when you are unable to create the class externally? Unfortunately the 4 args constructor in line 79 is protected, which would solve my problem since I then could just provide the required args. Or is this a bug I should report?

I appreciate any help,

Cheers, Fritz

[Fritz Gerald]

Hi,

Sorry for pushing this question, but I am in the middle of writing a little test Scala mapper and since this is crucial for further development design choice I am now stuck. I would be really thankful if someone could provide me any hint.

Cheers, Fritz

[machak]

Hi,

On Wednesday, April 8, 2015 at 1:05:10 PM UTC+2, Fritz Gerald wrote:

Hi,

Sorry for pushing this question, but I am in the middle of writing a little test Scala mapper and since this is crucial for further development design choice I am now stuck. I would be really thankful if someone could provide me any hint.

I don't think this is going to work. 

see [1] for an example how to create Edges.

cheers

/m

[1]  http://www.orientechnologies.com/docs/last/orientdb.wiki/Graph-Database-Tinkerpop.html

 

Cheers, Fritz

[Fritz Gerald]

Hi,

thanks for your comment, but I knew of the docs. 

I am just surprised, since one normally defines interfaces and marks classes as protected / private when you do not want anyone to create an instance of a classes but still allow access to it. It is just quite unusual to create public class that can cause unhandled exceptions so I think there was a design purpose by the developers of OrientDB.

Maybe some OrientDB official in this thread can say something ;-)

Cheers, Fritz

[machak]

On Wednesday, April 8, 2015 at 3:50:54 PM UTC+2, Fritz Gerald wrote:

Hi,

thanks for your comment, but I knew of the docs. 

I am just surprised, since one normally defines interfaces and marks classes as protected / private when you do not want anyone to create an instance of a classes but still allow access to it. It is just quite unusual to create public class that can cause unhandled exceptions so I think there was a design purpose by the developers of OrientDB.

Maybe some OrientDB official in this thread can say something ;-)

actually, looking into code you see:

/**
 * (Internal) Called by serialization
 */
public OrientEdge() {
  super(null, null);
}

 

cheers,

/m

[Fritz Gerald]

Hi,

Thanks, I saw that as well. It is just that comments should no be used to limit functionality and for sure a comment should list all aspects of the behavior (see JavaDoc best practice). In this case I would still recommend to convert the JavaDoc "Internal ..."  info into a private class declaration. In addition I do not see any reason for the limitations of the constructors.

However, it seems it is just not possible.

Cheers, Fritz