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.
