sandrokeil / arangodb-php-driver Goto Github PK

It looks like the ArangoDB GO driver is more mature than the c++ driver. So we can use them and call it from c++.

GO has different build modes, so maybe it's really easy to use. /cc @martin-schilling

As soon as the basic port from PHP-CPP to ZendEngine is done we should start heavily optimizing the code and cover as much of it with tests as possible.

We should find a possibility to replace the Type inspectors with working directly on velocypack data for faster checks. This is especially needed for lager transactions/responses.

Succesful response

{
    "code": 200,
    "error": false,
    "result": {
        "rId0": [
            {
                "_id": "c878c0b7e51ecaab95c511fc816ad2a70c9418208/100000000000000001",
                "_key": "100000000000000001",
                "_rev": "_WAf0iN----"
            },
            {
                "_id": "c878c0b7e51ecaab95c511fc816ad2a70c9418208/100000000000000002",
                "_key": "100000000000000002",
                "_rev": "_WAf0iN---_"
            }
        ]
    }
}

Error response single type

Attention: Root error key is false, but individual result has "error": true,.

{
    "code": 200,
    "error": false,
    "result": {
        "rId0": [
            {
                "_id": "c878c0b7e51ecaab95c511fc816ad2a70c9418208/100000000000000001",
                "_key": "100000000000000001",
                "_rev": "_WAg_9aK---"
            },
            {
                "_id": "c878c0b7e51ecaab95c511fc816ad2a70c9418208/100000000000000002",
                "_key": "100000000000000002",
                "_rev": "_WAg_9aK--_"
            },
            {
                "error": true,
                "errorMessage": "unique constraint violated - in index 0 of type primary over [\"_key\"]",
                "errorNum": 1210
            }
        ]
    }
}

Error response multiple types

Attention: Root error key is false, but individual result has "error": true,.

{
    "code": 200,
    "error": false,
    "result": {
        "rId0": [
            {
                "_id": "c878c0b7e51ecaab95c511fc816ad2a70c9418208/100000000000000001",
                "_key": "100000000000000001",
                "_rev": "_WAgC_wq---"
            },
            {
                "_id": "c878c0b7e51ecaab95c511fc816ad2a70c9418208/100000000000000002",
                "_key": "100000000000000002",
                "_rev": "_WAgC_wq--_"
            }
        ],
        "rId1": [
            {
                "error": true,
                "errorMessage": "unique constraint violated - in index 0 of type primary over [\"_key\"]",
                "errorNum": 1210
            },
            {
                "error": true,
                "errorMessage": "unique constraint violated - in index 0 of type primary over [\"_key\"]",
                "errorNum": 1210
            }
        ]
    }
}

I would suggest to only find the first error object and transform it to an exception. A method to get all errors would be nice too. The error object under result has the following structure:

{
    "error": true,
    "errorMessage": "unique constraint violated - in index 0 of type primary over [\"_key\"]",
    "errorNum": 1210
}

Would be nice if there is a faster lookup instead of iterating through each result.

PHP-CPP is not an optimal choice due the limitations and dependency. Development was started in https://github.com/sandrokeil/arangodb-php-driver/tree/port-everything-to-zend

We have to redefine the possible parameters for each HTTP verb method. For instance, delete don't support a request body but query params. Useless creation of Vpack can be avoided and it's a much cleaner API.

This extension must be run on different linux system especially on Alpine Linux (Docker Images). There exists a php-cpp issue for this.

Since objects are created through PHPs ecalloc() which internally uses malloc() the constructors are not called. This can be fixed through the usage of a placement new which should be added to all objects relying on a constructor. The same applies for the desctructors which means that more custom object handlers must be implemented and the desctructor has to be called manually (eg intern->~Connection())

We need a cursor / statement API implementation to iterate over results. See also ArangoDb blog post.

Full example can be found here.

        $statement = new Statement(
            $this->connection, [
                Statement::ENTRY_QUERY => str_replace('%filter%', $filter, $aql),
                Statement::ENTRY_BINDVARS => array_merge(
                    [
                        '@collection' => $this->eventStreamsCollection,
                        'offset' => $offset,
                        'limit' => $limit,
                    ],
                    $values
                ),
                Cursor::ENTRY_FLAT => true,
            ]
        );
        $streamNames = [];
        foreach ($statement->execute() as $streamName) {
            $streamNames[] = new StreamName($streamName['real_stream_name']);
        }
        return $streamNames;

@martin-schilling We have to shape the API for these classes. Your thoughts?

After the call to create the testobi collection, the program does not exit.

Create own exceptions under the ArangoDb namespace and use them instead of Php::Exception.

First, we need a connection class. The ArangoDBClient/Connection.php is a good blueprint, but we have to use the fuerte style / features.

Requirements

• Handling of different databases, maybe one connection for every database
• Async handling of different requests, use callable ?
• Request / Response classes
• Connection option class / constants

Questions

• Should we share a connection between HTTP Requests / CLI ? We use bi-directional async velocystream protocol.

Sending requests asynchronously fails somewhere in the range between 100-500. Might be a memory issue.

The driver should be tested for different Linux and PHP versions.

• PHP >= 7.1
• Debian / Ubuntu / Alpine

There is a compiling error if we use a response.cpp. We should find the reason. Maybe a typo ...

The new implementation based on the Zend engine probably contains a bunch of memory leaks. We have to find and fix them appropriately.

Velocypack features a CharBufferSink (https://github.com/arangodb/velocypack/blob/master/include/velocypack/Sink.h#L74) which might be significantly faster than the StringSink combined with .c_str() so we should consider using that

The code structure is not optimal now so we should find a clean solution and clean it up accordingly.

Something like this here

We should start with a wrapper for a simple class of fuerte/veloycpack to see how things work. The Yothalot-PHP extension could be a blueprint for this.

In some occasions it might be worth performance wise to not write classic getters like Response::get_body() and return that to PHP using RETURN_STRING but to write a return function Response::return_body(zval* return_value) instead. In this case this would save passing around a std::string (or additional changes to enable return by reference / smart_ptr). This is a little bit ugly though so smart_ptrs might actually be a better solution. One way or another we should find a good solution for this and use it constantly throughout the codebase.

To avoid runtime errors, we should add a check for undefined symbols/references in the build process.

We have to create wrapper classes for fuerte/message.

In the current simple test implementation I got the error.

php: symbol lookup error: /usr/lib/php/20160303/arangodb.so: undefined symbol: _ZN8arangodb10velocypack13valueTypeNameENS0_9ValueTypeE

After #3 was resolved, new error occurred.

/usr/bin/ld: //usr/local/lib/libvelocypack.a(Builder.cpp.o): relocation R_X86_64_TPOFF32 against `_ZGVZN8arangodb10velocypack7Builder19sortObjectIndexLongEPhRSt6vectorImSaImEEE7entries' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libvelocypack.a(Slice.cpp.o): relocation R_X86_64_PC32 against symbol `_ZN8arangodb10velocypack15SliceStaticData7TypeMapE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:132: recipe for target 'arangodb.so' failed
make: *** [arangodb.so] Error 1

How to resolve this?

This is a reminder that we have to use VST 1.1 if Bug with Velocystream v1.1 is resovled.