We are well aware that this is no small undertaking, but we believe in OrientDB and we think it's worthwhile.
> one big step is actually implement the serialize/deserialize of hte document correctly from the binary serialization To my knowledge, that has not been done in php yet, by anyone? All existing implementations, including the fork by Ostico, support only the CSV style serialization. The binary serialization format actually ought to be a lot easier to implement, as it won't require a state machine/parser like the CSV format - and also should be a lot more CPU friendly, memory efficient, and less bandwidth overhead, so we're targeting that exclusively. We're also targeting the most recent protocol, which already differs substantially from what we were able to reference from existing implementations, which are based on older versions of the protocol. We hope to support the final version of the protocol when OrientDB 2.0 is released - we do not want this client library to only support a legacy protocol from inception. As said though, it doesn't appear that REQUEST_RECORD_LOAD respects the serializer setting - it appears to always return records in the CSV format. If this a missing feature or server-side issue, we won't get very far with our client anytime soon... Either way, we need someone who can at least answer the question and help set us on the right path. At this moment, we are stalled, since we don't even know if the server is behaving correctly, or whether we need to support the CSV format or not. On Tue, Dec 9, 2014 at 4:57 PM, Emanuel <[email protected]> wrote: > We have also other drivers php this one > https://github.com/orientechnologies/php-orientdb that also already have > a few forks (example this : https://github.com/Ostico/PhpOrient ). > > i would like to say that is better have less drivers more update and i > warn you, write a driver from scratch is not so easy as it seems :) > > anyway you are free to do so ;) > > one big step is actually implement the serialize/deserialize of hte > document correctly from the binary serialization, that is quite complex and > can be also target of evolution/optimization in not to far future. > > Here in orient we are evaluating to give an easier way to read/write the > document on the binary protocol, but i will open another thread on this :) > > bye > > Emanuel > > > On 12/09/2014 11:48 AM, Rasmus Schultz wrote: > > Doctrine is the only one of those projects that still have any traction - > and it's a full scale data mapper, what we need is a simple driver/client. > > We are of course referencing those projects for lots of implementation > details, but we're shooting for something much simpler and more low-level, > something people can use to build their own mappers/DAO/AR implementations > on top of. > > We're also designing the whole thing using very basic OOP patterns (no > traits) in the hopes of porting this to a native extension (e.g. Zephir) > eventually. > > We're also designing the whole thing with zero dependencies on other > libraries. > > So we have somewhat different objectives from the other projects, and > more of a minimalist mindset, I think. > > > On Tue, Dec 9, 2014 at 12:36 PM, 'Curtis Mosters' via OrientDB < > [email protected]> wrote: > >> Well there is no other Google Group. But why not use the Github already >> existing PHP OrientDB projects? >> >> https://github.com/AntonTerekhov/OrientDB-PHP >> https://github.com/doctrine/orientdb-odm >> https://packagist.org/packages/orientdb-php/orientdb-php >> >> I don't know but this would be way better to do it there. WDYT? >> >> Am Dienstag, 9. Dezember 2014 11:38:07 UTC+1 schrieb mindplay.dk: >> >>> Is there a different group for developers with more technical questions? >>> >>> I want to help bring OrientDB to php - is this the right place for >>> that? Or is nobody interested? >>> >>> >>> On Monday, December 8, 2014 5:19:07 PM UTC+1, mindplay.dk wrote: >>>> >>>> I'm trying to tackle REQUEST_RECORD_LOAD as the first useful function >>>> in my PHP client. (I have the basics like connect and open, error handling, >>>> etc. working so far.) >>>> >>>> This being a PHP client, one major concern for me, is to avoid >>>> parsing (with a state machine, as was necessary with the old format) since >>>> this is extremely inefficient in PHP - this is one reason I'm targeting >>>> OrientDB 2.0 and the new binary format exclusively, as this appears to make >>>> that possible (?) >>>> >>>> Unfortunately, the response format of REQUEST_RECORD_LOAD itself >>>> appears to make that impossible. >>>> >>>> >>>> [(payload-status:byte)[(record-content:bytes)(record-version:int)(record-type:byte)]*]+ >>>> >>>> In order to read sequentially over "record-content", I need to know >>>> the "record-type" in advance, so the order of this data appears to be >>>> wrong? I believe the record format of each payload chunk would need to >>>> backwards, basically: >>>> >>>> >>>> [(payload-status:byte)[(record-type:byte)(record-version:int)(record-content:bytes) >>>> ]*]+ >>>> >>>> Otherwise, I am forced to load the whole record-content into memory >>>> first, before I can know how to interpret the data. >>>> >>>> Or am I missing something here? >>>> >>>> Also, it appears the "record-content" is in the old CSV format, >>>> regardless of my having selected the new binary serialization format? Does >>>> the REQUEST_RECORD_LOAD command not support the new binary serialization >>>> format? Is it not supported everywhere yet? >>>> >>>> I really do not want a client that has to load and then parse in two >>>> stages - this adds considerable complexity, run-time overhead, and >>>> duplicates everything in-memory while loading. I'm probably doing something >>>> wrong or missing something obvious? >>>> >>>> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "OrientDB" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/orient-database/9CKEun_WrrA/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > > --- > 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/d/optout. > > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/9CKEun_WrrA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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/d/optout.
