Looks like your implementation is a source to source port? So I'm none the wiser.
This may be possible in PHP, but it's going to be based on horrible work-arounds, it will be slow, and it will have some ugly limitations. Really sad to get this far and have to drop the whole thing because of such a small trivial technical thing, but this is obviously not a good fit for PHP, and with the limitations this will have, it doesn't seem like it's going to be worth the effort. Now thinking about writing a binary driver in Zephir. But I really don't want a PHP module for something that is without a doubt going to need ongoing maintenance and continuous upgrades. The only other option is the REST API, which might be a more realistic choice for PHP - this was actually my first choice, because PHP isn't really suitable for a binary driver, I guess I hadn't realized yet just *how* unsuitable it is... However, I gave up on the REST API earlier, because it turns out it denormalizes links: https://groups.google.com/forum/#!topic/orient-database/EKPK0oBK1i8 Should I file this as a bug report? I guess it might be "by design", but it seems like a strange choice - why wouldn't it work just like the binary API, just with data-structures in JSON of course, but not with substantial differences in terms of the data/structures you get in a response? And certainly not duplicating data structures, which adds unnecessary encoding overhead on the server, network overhead, and decoding overhead on the client... On Fri, Dec 12, 2014 at 8:26 PM, GoorMoon <[email protected]> wrote: > sorry for PHP :), > > look in the class OVarIntSerializer.java > here > https://github.com/orientechnologies/orientdb/tree/master/core/src/main/java/com/orientechnologies/orient/core/serialization/serializer/record/binary > > On Friday, December 12, 2014 8:12:49 PM UTC+2, mindplay.dk wrote: >> >> There is no byte type in PHP, hahaha... I know, right?! :-) >> >> There is only one integer type in PHP, and it's always signed, and always >> 32-bit or 64-bit depending on your hardware and OS. >> >> So of course you can juggle values within byte-range, but you can't do >> unsigned bit arithmetic because there is no unsigned integer type, so it's >> going to be clunky. >> >> And it's going to be horrendously slow since every byte you're working >> with is actually 32 or 64 bits, and every arithmetic or bitwise operation >> is actually a full word or long-word operation. >> >> All in all, writing it in PHP probably isn't a good choice to begin with, >> as PHP just isn't suitable for this kind of low-level stuff. >> >> My colleague suggests writing a PHP module wrapper for the C API, but >> that's not a great option either - proliferation is a really big concern >> for me, I'd like to have something you can deploy in most hosting >> environments without building a custom extension. >> >> I really hope to see OrientDB catch on and become a real alternative to >> MySQL, but step one is a working client. I'm not even a fan of PHP >> particularly, but it is the leading web platform, and it's what I do for a >> living, so... :-) >> >> Where in the OrientDB codebase is variable-size integers implemented? >> >> Or is a native Java feature? If so, it must be documented somewhere? >> >> This is a huge roadblock for something that should be trivial, so I can >> get to implementing the actual protocol and client - the documentation >> really needs to include a proper description and/or links and/or reference >> implementation, preferably all of those... I am completely in the dark here. >> >> >> On Fri, Dec 12, 2014 at 5:51 PM, GoorMoon <[email protected]> wrote: >>> >>> What if you use byte array to represent and manipulate variable-size >>> integers ? >>> >>> On Friday, December 12, 2014 4:56:57 PM UTC+2, mindplay.dk wrote: >>>> >>>> Yikes, I blew my entire day on this. >>>> >>>> Can't find a PHP implementation, can't get a port to work, because PHP >>>> only has one numeric type, and it's a 32-bit signed integer. >>>> >>>> What's worse, it's platform-dependent and could be either 32-bit or >>>> 64-bit. >>>> >>>> I'm afraid we're at a dead end with this client, unless somebody else >>>> can figure out how to read/write variable-size integers, or unless OrientDB >>>> offers a protocol option for clients in languages that don't have proper >>>> support for native numerical types... man, PHP stinks :-( >>>> >>>> >>>> On Fri, Dec 12, 2014 at 12:53 PM, Rasmus Schultz <[email protected]> >>>> wrote: >>>>> >>>>> I know, but that's hardly a specification - not enough to reference >>>>> for an implementation. >>>>> >>>>> For now, I will try to port your implementation... >>>>> >>>>> >>>>> On Fri, Dec 12, 2014 at 12:49 PM, GoorMoon <[email protected]> wrote: >>>>>> >>>>>> You can look hear https://github.com/orientechnologies/orientdb/wiki/ >>>>>> Record-Schemaless-Binary-Serialization#shortintegerlong >>>>>> >>>>>> >>>>>> On Friday, December 12, 2014 1:44:01 PM UTC+2, mindplay.dk wrote: >>>>>>> >>>>>>> Glad to hear that, thanks :-) >>>>>>> >>>>>>> So on a related note - the "varint" type used in the OrientDB binary >>>>>>> protocol, what specification does it follow precisely? Because >>>>>>> apparently >>>>>>> there are lots >>>>>>> <http://vpri.org/fonc_wiki/index.php/Variable_Length_Integer> of >>>>>>> ways to encode a variable-size integer. >>>>>>> >>>>>>> I sort of wish there was an option for the client to disable >>>>>>> variable-length integers in the protocol, instead encoding them with a >>>>>>> fixed size. >>>>>>> >>>>>>> I can implement UTF-8 style reading/writing of variable-size >>>>>>> integers in PHP, but this is going to add considerable CPU overhead - in >>>>>>> the case of a PHP client (probably other scripting languages too) a >>>>>>> small >>>>>>> amount of bandwidth overhead is likely preferable to CPU overhead. What >>>>>>> we >>>>>>> want is a fast client - whether that means using a little more >>>>>>> bandwidth is >>>>>>> probably secondary, as is the ability to support more than 2 billion >>>>>>> records for most projects. >>>>>>> >>>>>>> Just putting that out there :-) >>>>>>> >>>>>>> But for the time being, can you point me to a specification or >>>>>>> (better) a reference implementation (in any language) of the VLI >>>>>>> encoding >>>>>>> used by OrientDB? >>>>>>> >>>>>>> I can reference the one in GoorMoon's .NET driver >>>>>>> <https://github.com/orientechnologies/OrientDB-NET.binary/blob/binary.serialization/src/Orient/Orient.Client/Protocol/Serializers/RecordBinarySerializer.cs#L502>, >>>>>>> or the one on wikipedia <http://en.wikipedia.org/wiki/UTF-8>, but >>>>>>> neither of them appear to have tests, and I'm unsure how to test them. >>>>>>> Go >>>>>>> has a nice implementation >>>>>>> <http://golang.org/src/encoding/binary/varint.go> with tests >>>>>>> <http://golang.org/src/encoding/binary/varint_test.go>, but since >>>>>>> there are so many types of VLI which don't appear to have any official >>>>>>> names or standardization, I can't be sure it's the same type of >>>>>>> encoding... >>>>>>> >>>>>>> >>>>>>> On Fri, Dec 12, 2014 at 11:45 AM, Luca Garulli <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Authors of drivers have such kind of high priority on requests :-) >>>>>>>> >>>>>>>> Lvc@ >>>>>>>> >>>>>>>> >>>>>>>> On 11 December 2014 at 23:29, GoorMoon <[email protected]> wrote: >>>>>>>> >>>>>>>>> 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]> 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]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Posted here >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/orientechnologies/orientdb/issues/3175 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 11, 2014 at 7:10 PM, GoorMoon <[email protected]> >>>>>>>>>>>> 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.bin >>>>>>>>>>>>>>> ary >>>>>>>>>>>>>>> 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/op >>>>>>>>>>>>>>>>>> tout. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> 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 orient-databa...@googlegroups. >>>>>>>>>>>>>>>>> com. >>>>>>>>>>>>>>>>> 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_Wrr >>>>>>>>>>>>>>> A/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_Wrr >>>>>>>>>>>>> A/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/to >>>>>> pic/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]. > 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.
