Support of Typed graph

40 views
Skip to first unread message

e.cou...@gmail.com

unread,
Feb 3, 2015, 9:20:12 AM2/3/15
to ferma...@syncleus.com
Hello,

I would like to migrate from Frames to Ferma or Totorum, I prefer your solution because you have kept the Frames annotations.
On the other hand, I’m not sure Ferma would allow me to implement the following features ? :

- Typed graph :
    The ability to have the right type of a vertex to have the ability to make polymorphic method call.
- Custom annotation :
    In my Frame projet I have defined a "DoubleAdjacency" annotation witch is an Adjcaency annoation with special feature, is it possible to do the same with ferma?
- Scala Option support :
    Because I'm working with scala I like optional type, because Frames do not allow the implementation of annotated method it's was impossible to convert null-able result to optional result. This last feature is probably possible because ferma allows classes to be annotated.


Cheers 

Etienne

SeH H

unread,
Feb 3, 2015, 11:49:10 PM2/3/15
to e.cou...@gmail.com, ferma...@syncleus.com
Hi Etienne--

I'm not familiar enough with Ferma's design to answer the polymorphic and custom annotation questions, so let's wait for a response to those from Jeff, its main developer.

I did some testing of Ferma through some of the first design iterations, and saw how its design solves the major issues we found with Frames and Totorum which necessitated Ferma's creation.  Therefore I guess that the features you describe, if not already present in Ferma, would likely benefit from those solutions and be implementable with the least trouble compared to the others.  Also, I guess that Jeff would be glad to add these useful features to the code.

In the meantime, if you would like to begin any changes or improvements, feel free to ask questions here.  If I can't answer it, Jeff can. (when he is available, which should be within days at the most)

It might help if you can develop some unit tests which illustrate the features you've described, and we can work backwards trying to make them pass in a way that is consistent with Ferma's design.

Ferma currently is pure Java, but it would be interesting to see what a Scala (or Clojure, etc...) wrapper API can provide.  You may want to start a "ferma-scala" sub-project which we could include as a separate maven dependency specifically for use in Scala projects.

--Seth

--
You received this message because you are subscribed to the Google Groups "Ferma List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ferma-list+...@syncleus.com.
To post to this group, send email to ferma...@syncleus.com.
To view this discussion on the web visit https://groups.google.com/a/syncleus.com/d/msgid/ferma-list/baafcc1a-36d3-4791-b286-14345c148ebe%40syncleus.com.

Jeffrey Freeman

unread,
Feb 4, 2015, 5:46:48 AM2/4/15
to Etienne Couritas, ferma...@syncleus.com

Im not sure what you mean by scala support in this context.  Can you elaborate?  All the other features should be possible however.  Im on my phone right now however.  Give me a few hours to find wifi (im out right now) and i will give you a more detailed response with some details. If any of these features arent present id be happy to implement them for you as well.

--

e.cou...@gmail.com

unread,
Feb 4, 2015, 7:53:54 AM2/4/15
to ferma...@syncleus.com, e.cou...@gmail.com
Hello Seth.

I read furemore in the ferma code and I think the unit test already exist here

For the support of scala I would like to have 
@Property
def getMyOptionalValue : Option[String]

witch return Some(myValue) or None if myValue do not exist on the edge.
I think i could do this by adding here, some thing like : returnOptional. 
After I wonder how can I mix scala reflection with java reflection, probaly by extending ReflectionUtility
Annother thing, I seen that   String TYPE_RESOLUTION_KEY = "ferma_type"; in this file. I don't use "ferma_type" to store my class name in my actual graph, there is some method set this value ? 
Into Frame it's available via @TypeField

Jeffrey, do not worry if you are on vacation, I can wait.

fre...@gmail.com

unread,
Feb 4, 2015, 2:00:56 PM2/4/15
to ferma...@syncleus.com, e.cou...@gmail.com
Hey, so I finally got a chance to sit down. I'm currently in the Netherlands (native to America though) so my schedule matches that time zone. Anyway let me try to address some of your concerns while I have a WiFi connection (I am walking around utretch exploring so I'm in and out of WiFi spots periodically).

Typed Graphs in Ferma is handled with all the same features as Tototrom and Frames however there is some additional flexibility you wont get with those frame works. For example Totorom provides a Typed mode and an Untyped mode but doesnt allow you to intermix the two modes. In Ferma you have that option. If you are in Typed mode you're types will resolve as you requested. However you will notice several methods of the signature *Explicit. These methods essentially temporarily bypass the typing and use an untyped mode. In untyped mode the type of the class isnt set and the type requested is always the type constructed. I know you didn't request this feature but I wanted to know you have the ability to freely switch between typed and untyped modes. But as you pinted out with the unit test that requirement is easily addressed with Ferma.

As for custom annotations, it is currently possible, However I plan to make it easier. Since this is a feature you are requesting I can make this more accessable to you in the next few days (unless you'd like to help contribute that yourself). Basically what you will have to do is write your own annotation and then write a method handler class for the annotation. Take a look at the Ferma built-in annotations to give you an idea as to how to write your own annotations. Here is an example of the Adjacency Annotation: 
https://github.com/Syncleus/Ferma/blob/master/src/main/java/com/syncleus/ferma/annotations/AdjacencyMethodHandler.java

and here is the Adjacency annotation method handler:
https://github.com/Syncleus/Ferma/blob/master/src/main/java/com/syncleus/ferma/annotations/Adjacency.java

If you write your own annotation handler and annotation modeled after these examples then you should be most of the way there. The only other issue is how to tell Ferma about your new annotation handler. With the way the current code is written you would need to write your own FrameFactory. Again to see an example of how to do that you can look at the built in AnnotationFrameFactory here:

https://github.com/Syncleus/Ferma/blob/master/src/main/java/com/syncleus/ferma/annotations/AnnotationFrameFactory.java

Of course if you write your own FrameFactory you will probably want to use most of the built-in annotations along side your own annotation still. That is where Ferma could be fixed a bit. I should add the ability for you to easily extend from the existing AnnotationFrameFactory to add your own annotations. So that is something I'd be happy to add for you to make your life much easier (it is on my to-do list anyway). Give me about 2 days and I should have that implemented for you.

As for Scala support, that is something I can't help with too much. I myself don't know Scala very well. However if you would like to add a scala layer I would be more than happy to officially endorse it as part of Ferma if it works.

While I write that new feature in for you let me know if there is anything else I could help with. I should be available a great deal this week so I'd be happy to help with anything you need.

fre...@gmail.com

unread,
Mar 3, 2015, 8:19:30 AM3/3/15
to ferma...@syncleus.com, e.cou...@gmail.com, fre...@gmail.com
Did this answer all your questions?

Etienne Couritas

unread,
Mar 3, 2015, 8:30:05 AM3/3/15
to fre...@gmail.com, ferma...@syncleus.com
Hello Jeffrey.

Sorry for the response time, we have put our backend in production and now I could say I don't have any time to make R&D.
But not this not answer all my questions, especially about TYPE_RESOLUTION_KEY , as I said we have use another property name, it's would be nice if we can change the value of type_resolution_key..

If there is not to many blocking point I'm pretty confident that we will use ferma to replace frame.


ps : sorry for my english, I didn't have the time to give it to a translator

 



Cordialement,

Etienne Couritas
tel 06 33 82 47 62
mail e.cou...@gmail.com
addr 26 rue de visien 92400 Courbevoie

SVP, envoyez-moi un accusé de réception. Merci.
Please, send me acknowledgment of receipt. Thanks.

fre...@gmail.com

unread,
Mar 3, 2015, 10:32:06 AM3/3/15
to ferma...@syncleus.com, fre...@gmail.com, e.cou...@gmail.com
No problem. What sort of time line do you have? I looked into implementing that feature to you but would be a bit more involved than I first thought. But it is something that should be done and I'm happy to implement it. I just need an idea of your timeline so I can prioritize it.

fre...@gmail.com

unread,
Mar 22, 2015, 11:25:32 AM3/22/15
to ferma...@syncleus.com, fre...@gmail.com, e.cou...@gmail.com
Hello again. I implemented this feature for you. Take a look and tell me if you have any feedback and if this meets your needs. Thanks.

Here is the specific commit diff:

Jeffrey Freeman

unread,
Mar 22, 2015, 11:59:25 AM3/22/15
to ferma...@syncleus.com, fre...@gmail.com, e.cou...@gmail.com

I just released version 2.0.5 and included the type resolution changes we talked about here in that release. You should now be able to use that feature int he official releases. Let me know if you find any bugs or have any comments, thanks.
Reply all
Reply to author
Forward
0 new messages