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] <javascript:> > > 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/orientechno >>>>>>>>>>>> logies/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/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_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/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] <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.
