New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to represent Entity in Edge API? #14

Closed
otaviojava opened this Issue Jan 11, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@otaviojava
Member

otaviojava commented Jan 11, 2018

The Currently model

/**
 * @param <IN>  the inbound Entity
 * @param <OUT> the outbound entity
 */
public interface EdgeEntity<OUT, IN> {

    /**
     * Gets the inbound entity
     *
     * @return the inbound entity
     */
    IN getInbound();

    /**
     * Gets the outbound entity
     *
     * @return the outbound entity
     */
    OUT getOutbound();
}

However, this current version does not support very well when there are more than one Edge types, e.g.: give this code:

        Person ada =...; 
        Technology java = ...;
        Technology cloud = ...;

       graph.edge(ada, "lives" "Sao Paulo");
       graph.edge(ada, "works", cloud);
       graph.edge(ada, "works", java);

01

EdgeEntity<Person,?> edges = graph.getTraversalEdge();
//that gonna return both: cities and technology edge

That makes me not full confidence in this current API.

The Options that I have in my mind:

what I thought:

1) Keep this existing API

2) Changes to add generics in the methods with throw class cast exception:

public interface EdgeEntity {

T <T> getInbound();

T <T> getOutbound();
}

3) Make the methods to return Object:

public interface EdgeEntity {

Object getInbound();

Object getOutbound();
}

4) another suggestion

To know more about Graph API: https://dzone.com/articles/have-a-fun-moment-with-graph-and-java

@otaviojava

This comment has been minimized.

Show comment
Hide comment
@otaviojava

otaviojava Jan 11, 2018

Member

I like the Option 2

Member

otaviojava commented Jan 11, 2018

I like the Option 2

@jesse-gallagher

This comment has been minimized.

Show comment
Hide comment
@jesse-gallagher

jesse-gallagher Jan 11, 2018

Unless there ends up being another clever way around it, I like option 2 as well, mostly on the basis that the logical thing to do after fetching is to do a class cast anyway, and users could pick Object themselves if they can't be sure at the time.

jesse-gallagher commented Jan 11, 2018

Unless there ends up being another clever way around it, I like option 2 as well, mostly on the basis that the logical thing to do after fetching is to do a class cast anyway, and users could pick Object themselves if they can't be sure at the time.

@otaviojava

This comment has been minimized.

Show comment
Hide comment
@otaviojava

otaviojava Jan 11, 2018

Member

Nice, I also shared it in the tinkerpop email list:
https://groups.google.com/forum/#!topic/gremlin-users/QO8paXoqJ7A

Member

otaviojava commented Jan 11, 2018

Nice, I also shared it in the tinkerpop email list:
https://groups.google.com/forum/#!topic/gremlin-users/QO8paXoqJ7A

@furlaneto

This comment has been minimized.

Show comment
Hide comment
@furlaneto

furlaneto Jan 12, 2018

Member

I prefer option 2 too because if we want the object we can get after like @jesse-gallagher said

Member

furlaneto commented Jan 12, 2018

I prefer option 2 too because if we want the object we can get after like @jesse-gallagher said

@otaviojava

This comment has been minimized.

Show comment
Hide comment
@otaviojava

otaviojava Jan 14, 2018

Member

So, let's keep the option 2.

Member

otaviojava commented Jan 14, 2018

So, let's keep the option 2.

@otaviojava otaviojava closed this Jan 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment