Hi guys,
thanks to focus on this topic. I'm open to any cool idea to improve out SQL
language. Please can you write a couple of example to Cypher query against
OrientDB SQL to understand:
1) what is missed in OrientDB, maybe as Charles said we could implement new
functions
2) if we already can use an improved syntax in OrientDB, so improve the
documentation on it

Lvc@



On 6 March 2014 13:35, Ameer Tamboli <[email protected]> wrote:

> I am modeling the database for one application now. After so much of
> deliberation, I have decided not to use Tinkerpop/Gremlin just to use other
> powerful features of OrientDB. But I miss the power of Cypher here. Having
> said that, I would vote for a Cypher like language which can leverage the
> power of OrientDB features than actual support for Cypher.
>
>
> On Thursday, 6 March 2014 03:09:58 UTC+5:30, EJ wrote:
>>
>> I have to admit that I am not the biggest fan of standards (Corba or
>> OpenGL anybody?) - sometimes they simply limit innovation to much.
>>
>> I have used the blueprint implementations of neo4j, titan and orientdb
>> and have to say that they all have a special flavor (e.g. to use a fulltext
>> index) and it is not that simple to port from one platform to another.
>>
>> Would I prefer cypher or a cypher like language? Maybe something which
>> learns from cypher but extends it to take more of the orientdb features
>> into account.
>>
>> I have looked through some of the documents about Tinkerpop3 some time
>> age - probably a step into the right direction but I assume that with an
>> increasing number of implementations and stakeholders  further progress
>> will get slower. My feeling is that the Tinkerpop stack will have quite a
>> marketing value (which also has its benefits) but what I have seen so far
>> from the technology did not impress me to much.
>>
>> About your idea to implement "orient-cyper" on top of the blueprint
>> implementation seems rather problematic to me because the blueprint
>> interface is something like the least common denominator of graph databases
>> and access to the underlying orientdb functionality requires workarounds.
>>
>> The two directions would not have to interfere - although I have only
>> seen a small part of the orientdb sources I would (or will) start with an
>> implementation on top of the low level java api.
>>
>> cheers,
>>
>> EJ
>> On Wednesday, March 5, 2014 9:20:35 PM UTC+1, odbuser wrote:
>>>
>>> Having Cypher would be great but I wouldn't confuse that with "Tinkerpop
>>> is underselling OrientDB".  Tinkerpop will be extremely important for
>>> applications just like JDBC was for SQL.  Tinkerpop Blueprints is changing
>>> as well to become more powerful for graphs.  Without Blueprints even in its
>>> current form, I'm not sure that I'd be using OrientDB.  Deciding on one
>>> backend that is changing rapidly is too risky for me so leveraging
>>> 'standards' is a partial way to mitigate the risk.
>>>
>>> Are you asking for Cypher support or you want a Cypher like language
>>> that leverages all of the distinct advantages of OrientDB?
>>>
>>> If you just want Cypher, I wonder if it's possible to make it parallel
>>> to the Gremlin support so that it's built over Blueprints but still has an
>>> underlying OrientDB implementation that can optimize accordingly.  Have you
>>> looked through the Tinkerpop3 threads on the Gremlin group?  Most of that
>>> discussion is geared towards making Tinkerpop way more powerful than it is
>>> today but I don't know how that will line up with the various underlying
>>> databases.
>>>
>>>
>>>
>>> On Wednesday, March 5, 2014 1:25:35 PM UTC-5, Ameer Tamboli wrote:
>>>>
>>>> Yes. I think something like Cypher with OrientDB will be icing on the
>>>> cake. I am interested in this topic.
>>>> On 5 Mar 2014 22:14, "EJ" <[email protected]> wrote:
>>>>
>>>>> Hello Everybody,
>>>>>
>>>>> I have just finished writing a clojure wrapper for the tikerpop  layer
>>>>> of orientdb (all existing are outdated) and I have so say that the
>>>>> Tinkerpop stack is in my opinion a very weak solution for graph
>>>>> applications with orientdb!
>>>>>
>>>>> Many of the unique features of OrientDB (embedded list/maps/documents
>>>>> etc) are not or only with tricks available. To me it would make sense to
>>>>> reconsider the question if a "native" graph handling (including a query
>>>>> language) that does use the specific advantages of Orientdb would be so 
>>>>> bad
>>>>> after all. The SQL commands are fine for the work with documents but i
>>>>> found them rather uncomfortable for graphs compared with cypher.
>>>>>
>>>>> The background of my work is also the evaluation of OrientDB for the
>>>>> use at a large company but the entry barrier is high compared to other
>>>>> databases like neo4j.
>>>>>
>>>>> Many people will get used to neo4j because cypher is powerful, easy to
>>>>> learn and comes out of the box: Most applications start small and with
>>>>> smaller graphs the performance differences will not be obvious.
>>>>>
>>>>> To work with graphs on top of OrientDB you have to setup the db, get
>>>>> around with the Tinkerpop stack - especially gremlin (and groovy), and 
>>>>> plug
>>>>> in jung on top to have comparable functionality - quite a journey.
>>>>>
>>>>>
>>>>> I have been thinking about developing something on my own - is anybody
>>>>> interested in this topic?
>>>>>
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> EJ
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "OrientDB" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to