Complex

[promontis]

Hi Achim,

I'm trying to use blueprints.net, but I find it rather hard to understand what is going on.
I'd really like to use it, but it seems rather overengineered, and I might think other people would have to agree.
Is there any way to keep it flexible, but easier to use/understand?

Regards,

Michel

[ahzf]

Thanks for your interest in the project.
Yes, I'm a German engineer so I'm used to build BMWs ;)
Perhaps we can collaborate to simplify the API without losing its power and to improve the overall documentation. Just write down your first questions e.g. in the wiki and I will answer them there. After a couple of rounds I hope thing become understandable or they will be scheduled for refactoring ;)

Cheers...
Achim

[promontis]

Hehe, I think it is acceptable to compare it to a BMW ;) You're doing a great job and I'm honored if we can collaborate to simplify it. Ofcourse, without losing its power. Also thank you for responding this quickly.

I think it is better to discuss the complexity in this thread, instead of the wiki. My primary concern with the current approach are the generics, which seems to be a bit on steroids. I do reckon the power of a generic structure like this, but I have a few suggestion in making them more readable. I don't know if there are feasible, but I'll write them down anyhow.

1. Do we really need a generic structure like this? I mean, is the propertygraph not sort of a default standard within the graph database field? I want to refer to a source you most likely know, namely https://github.com/tinkerpop/blueprints/wiki/Graph-Morphisms
2. Could we group the typeparams? Currently, you are already grouping them in the XML documentation. This will reduce the size and make it more readable. So instead of 14 typeparams, we would only have three, grouped on Vertex, Edge and HyperEdge.
3. There are currently two primary types of graphs; a GenericGraph and a PropertyGraph. The seem to be unrelated in their interfaces. Both are defined in the blueprints project. Their implementation are defined in the GenericGraph project and in the InMemoryGraph project. I find this a bit confusion.

3a. I think we should have a more consistent naming. InMemoryGraph should be named PropertyGraph?
3b. I can imagine that people could think that a PropertyGraph is a concrete implementation of a GenericGraph. In the current implementation this is not the case, but should it be? Actually a question to you. The same goes for SimplePropertyGraph, which could a more concrete implementation of PropertyGraph.
3c. Personally, I would favor one project. So blueprints would also contain the implementation of the graphs.

Do note that some suggestions might be my lack of understanding, please feel free to correct me.

Cheers,

Michel

[Stephanvs]

Hi,

Given the Test Driven Design approach, would it be possible to identify what the ideal usage API looks like (and still contain all the functionalities) and after that, implement the thing piece by piece?

In my view the usage API should be really simple, clean and straightforward.. so one without any knowledge of graphs can failry easy pickup the libraries and start using them right away.

If you look at the original Java implementation of Blueprints, it's a really clean API... perhaps it's possible to leverage some of their interfaces and convert their generic structure to C#?

Cheers!

[ahzf]

Yes, generics are steroids, but they are a great tool for the compiler, intellicence and the developer to write better code faster (see Anders Hejlsberg's talk on C# 5.0 at the last BUILD). I have some none-standard property graphs running in production having not a <String, Object> typing, but are backed by enums, so we can have a strong typed property graph which is really awesome ;) (…at least for me ;) )
But as not everyone needs generics there is e.g. the SimplePropertyGraph<TId, TRevisionId, TLabel, TKey, TValue> setting most parameters to default values and even the SimplePropertyGraph implementation which has no generic parameters at all.

We could also define simplified interfaces, if this might clear things. But you have to account that this will lead to a problem with inheritance. If you have the following:
a) Interface iface
b) Interface iface _string : iface
c) class c1 : iface
d) class c2 : iface_string
You have to look a bit more to recognize that c1 and c2 might implement the same type of iface. Not that this is a really big problem, but perhaps a bit unexpected for new developers. But there might be a lot of situations in which this would make things easier.

Nearly the same problem occurs with the GenericGraph and PropertyGraph interfaces. Sure the PropertyGraph interface is more or less just a generic graph having KeyValuePairs on vertices and edges. BUT as in a graph everything references everything else the problem is that you have to decide which type to return when you traverse the graph. If graph.Vertices() would return a generic vertex you would have to do a cast when you want to access the properties of a property vertex.

What we would need is unfortunately at the moment not possible with C#. Even with co- and contravariance we cannot change the return type of methods so that the IPropertyGraph interface will return IPropertyVertices instead of IGenericVertices but is still derived from the the IGenericVertices interface.

The problem with the naming is 100% true. With respect to the Boost Graph library I want to support multiple graph representations (Adjacencylist) beside the pure class-based graphs of Tinkerpop. Currently there is e.g. some proof-of-concept code within Blueprints.NET which stores a graph as (RDF-)Quads. Another important thing will be 100% read-only property graph interfaces and implementations as this will allow us to do amazing things on multicore cpus ;)

I hope this might give a short glimpse on the resons for some decisions I made.
But I'm still open to rethink some of them ;)

[promontis]

Yes the talk with Anders was good, wasn't it. A colleague of mine attended the conference, and pointed it to me.

I've managed to discuss the complexity with some colleagues as well. (Un)fortunately we all think your solution is still the best. Other solution will mean loss of type safety and flexibility. So the generics are of the refactoring todo list. I do think it is still wise to write some wiki pages explaining the complex stuff, because it is scary to look at first :)

I do think we should relocate some classes though, for the sake of discoverability and overview. My idea would be to relocate the GenericGraph and InMemoryGraph project content to the Blueprints project, in a folder "Implementations". I would also opt for the convention to default the implementations to in-memory ones. So THE PropertyGraph would default mean an in-memory one. This way the following implementations would hold:

• PropertyGraph
• ReadOnlyPropertyGraph
• GenericGraph
• QuadStore

Eventually, I can image, we create graphs for other than in-memory, like Neo4j, OrientDB, DEX, etc. IMO these should go in new projects, and could be based on any of the graph interfaces inside the blueprints project.