Glad to hear !!! On Thursday, December 11, 2014 11:41:05 PM UTC+2, mindplay.dk wrote: > > Never mind, spotted it :-) > > > On Thu, Dec 11, 2014 at 10:03 PM, Rasmus Schultz <[email protected] > <javascript:>> wrote: > >> That was a fast decision - very happy to see them reacting to this issue >> so quickly and slating it for the 2.0 release! :-) >> >> So I'm referencing a bunch of your code for my client now, and I'm hung >> up on a small issue, maybe you can point me in the right direction... >> >> The so-called "varint" type in the binary serialization - I understand >> it's a variable-size integer, encoded like UTF-8 character codes. Where or >> how do you handle this in your implementation? >> >> >> On Thu, Dec 11, 2014 at 7:31 PM, Rasmus Schultz <[email protected] >> <javascript:>> wrote: >> >>> Posted here >>> >>> https://github.com/orientechnologies/orientdb/issues/3175 >>> >>> >>> On Thu, Dec 11, 2014 at 7:10 PM, GoorMoon <[email protected] >>> <javascript:>> wrote: >>> >>>> I am agree with you, but this not our decision. >>>> I suggest you to open issue here >>>> https://github.com/orientechnologies/orientdb that describe your >>>> purpose. >>>> >>>> >>>> On Thursday, December 11, 2014 10:55:46 AM UTC+2, mindplay.dk wrote: >>>>> >>>>> This looks great, thanks! So much simpler than the CSV serializer. >>>>> >>>>> I see that you do have to buffer the record in memory still, as I >>>>> suspected. I really do wish they would make the change I suggested below, >>>>> putting the record format before the actual record - I think then you >>>>> wouldn't need to buffer records in memory before you can deserialize. >>>>> Thoughts? >>>>> On Dec 10, 2014 1:09 PM, "GoorMoon" <[email protected]> wrote: >>>>> >>>>>> 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]> >>>>>>> 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 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 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.
