Hey, I don't know about PHP driver but, i contribute to .NET Driver https://github.com/orientechnologies/OrientDB-NET.binary i implemented a lot of features of Binary Serializer, and may help you with your question. About RECORD_LOAD i don't have any problem and get document in binary format.
On Tuesday, December 9, 2014 6:15:13 PM UTC+2, mindplay.dk wrote: > > 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] > <javascript:>> 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] <javascript:>> 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] <javascript:>. >>> 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] <javascript:>. >> 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] <javascript:>. >> 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.
