laravelfreelancernl / laravel-arangodb Goto Github PK

Needed for RefreshDatabase tests with view migrations.

The lengthawarepaginator executes a separate query to count the total the total number of results. However binds in the original query are lost which makes for incorrect results.

Method LaravelFreelancerNL\Aranguent\Query\Grammar::compileInsertOrIgnore does not exist.

ArangoDB's collect statement eliminates the local scope.
To return both the groupBy variable(s) and locally scoped data the selected collections and attributes need to be collected as well.

Aranguent is nearing the point where it can work with third party packages. I'm aiming to provide a smooth conversion with minimal extra steps for anyone implementing this driver.

If you have migrations you will need to publish and convert those.
If you have a model you will need to extend Aranguent's model or use the IsAranguentModel trait and override the key attributes (primaryKey & keyType).

These are the packages I'll be testing in the coming weeks/months:

• ✅ Laravel Horizon
• ✅ Spatie Medialibrary
• ✅ Spatie Permissions
• ✅ barryvdh/laravel-debugbar
• ❌ Laravel Pulse
• Laravel Passport
• Laravel Sanctum
• Spatie laravel-multitenancy
• Cashier Mollie

If you have any (popular) package you'd like to see tested please put them in a comment, or better yet: help out, test it and comment your findings or help out by improving Aranguent.

Move ADB specific console commands to its own namespace

See if this can be prevented by intelligently overriding Laravel commands

Transactions need to be refactored to ArangoDB's streaming transactions. This will bring them more in line with RDBMS style transactions.

https://documentation.divio.com/

Padding an array with nested data to firstOrCreate will break the search for an existing model.
Flattening it to a dot notation will break the insert. So this needs to be handled internally.

ArangoDB speaks boolean so something like where('published', true) should be turned into FILTER doc.published == true
instead we get: FILTER doc.published == 1

This should be true by default, and configurable to tinyInt for data migrations in case someone doesn't want to change the data itself.

From the looks of it these new query builder functions should work out of the box. To be confimed with tests.

$collection->foreignId('user_id')->index();

Argument 2 passed to LaravelFreelancerNL\Aranguent\Schema\Blueprint::createIndexName() must be of the type array, bool given, called in /srv/www/lf/evesdrop/vendor/laravel-freelancer-nl/aranguent/src/Schema/Concerns/Indexes.php on line 34

Laravel has added support for several new index types that were already supported by this driver.

Streamline the method names to align with Laravel

Add missing drop{index-type} methods

Deprecate fulltext index functions

I don't have a use case for this myself. So, if you need this functionality please help out by adding tests and fixes if necessary.

Discussed in #52

DB config (config/database.php)

    'connections' => [

        'arangodb' => [
            'name' => 'arangodb',
            'driver' => 'arangodb',
            'endpoint' => env('DB_ENDPOINT', 'tcp://localhost:8529'),
            'database' => env('DB_DATABASE'),
            'AuthUser' => env('DB_USERNAME'),
            'AuthPasswd' => env('DB_PASSWORD')
        ],

// ...

.env details are all correct

upon running php artisan passport:install --force

Encryption keys generated successfully.

   TypeError 

  Argument 1 passed to ArangoDBClient\Statement::__construct() must be an instance of ArangoDBClient\Connection, null given, called in .../app/vendor/laravel-freelancer-nl/aranguent/src/Connection.php on line 447

  at vendor/triagens/arangodb/lib/ArangoDBClient/Statement.php:255
    251|      *
    252|      * @param Connection $connection - the connection to be used
    253|      * @param array      $data       - statement initialization data
    254|      */
  > 255|     public function __construct(Connection $connection, array $data)
    256|     {
    257|         $this->_connection = $connection;
    258|         $this->_bindVars   = new BindVars();
    259| 

      +42 vendor frames 
  43  artisan:37
      Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))

ArangoDB supports several key generators. The default is 'traditional', somewhat akin to the MySQL auto increment generator.

If you want to use a different one throughout your project you now have to edit each migration file.

Making the key options configurable lets a user set it for all migration files. Some commands like autoincrement and uuid on either the 'id' or '_key' field should still override the default.

Add a ADB queue. The regular db queue driver uses transactions which need to be overridden.

Hi. Thank you for your package and work.

I have some concerns about upgrading to 0.10. Particularly, in this sentence in release notes:

"Using _id is slightly slower and more verbose than using _key however provides much more third-party package compatibility out of the box."

What's your opinion about "slightly slower" and is it good for intensive load application? And would you recommend to upgrade in this case.

Also, can you please explain or guide where to start digging, from where this "slightly slower" comes. I've use two queries with _id and _key and in both keys got index scan optimization:

L11 is out. Support it after the compatible testbench version is out.

`php artisan model:show User

TypeError

LaravelFreelancerNL\Aranguent\Connection::getTablePrefix(): Return value must be of type string, null returned

at vendor/laravel-freelancer-nl/aranguent/src/Connection.php:115
111▕ * Get the collection prefix for the connection.
112▕ /
113▕ public function getTablePrefix(): string
114▕ {
➜ 115▕ return $this->tablePrefix;
116▕ }
117▕
118▕ /*
119▕ * Disconnect from the underlying ArangoDB connection.

  +13 vendor frames 

14 artisan:35
Illuminate\Foundation\Console\Kernel::handle()
`

The artisan db:wipe command properly drops all collections, but leaves views in place.
The same is probably true for custom analyzers.

Requires 'from' transformation

• lists/listedBy/listedIn relation
• graph relation?

See Petry's enhanced postsql laravel driver

hi,

I have an error that I can't figure out how to fix it
when I launch php artisan migrate here is my error :

` ArangoClient\Exceptions\ArangoException

0 - cURL error 1: Protocol "tcp" not supported or disabled in libcurl (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for tcp://arangodb:8529/_db/laravel/_api/collection?excludeSystem=0

at E:\Test\HouseCMS\vendor\laravel-freelancer-nl\arangodb-php-client\src\ArangoClient.php:159
155▕ $code = (int) $decodedResponse->code;
156▕ }
158▕ throw(
➜ 159▕ new ArangoException(
160▕ $code . ' - ' . $message,
161▕ (int) $code
162▕ )
163▕ );

  ArangoClient\ArangoClient::handleGuzzleException()

2 E:\Test\HouseCMS\vendor\laravel-freelancer-nl\arangodb-php-client\src\Schema\ManagesCollections.php:33
ArangoClient\ArangoClient::request()`

db:monitor shows the active connection, but not the connection count.

Trying to implement arango on my new build, ran into this after installing the alpha version of aranguent (which, btw, was I supposed to do that differently? Just using the base install it threw a compatibility error, so I used the v1.0.0-alpha2 version)

2014_10_12_000000_create_users_table`` PHP Fatal error: Declaration of LaravelFreelancerNL\Aranguent\Schema\Builder::__call(string $method, mixed $args): void must be compatible with Illuminate\Database\Schema\Builder::__call($method, $parameters) in /home/bridgebrain/web/infinatummedia.com/public_html/vendor/laravel-freelancer-nl/aranguent/src/Schema/Builder.php on line 218

Symfony\Component\ErrorHandler\Error\FatalError

Declaration of LaravelFreelancerNL\Aranguent\Schema\Builder::__call(string $method, mixed $args): void must be compatible with Illuminate\Database\Schema\Builder::__call($method, $parameters)

at vendor/laravel-freelancer-nl/aranguent/src/Schema/Builder.php:218
214▕
215▕ /**
216▕ * Silently catch the use of unsupported builder methods.
217▕ */
➜ 218▕ public function __call(string $method, mixed $args): void
219▕ {
220▕ Log::warning("The Aranguent Schema Builder doesn't support method '$method'\n");
221▕ }
222▕ }

Whoops\Exception\ErrorException

Declaration of LaravelFreelancerNL\Aranguent\Schema\Builder::__call(string $method, mixed $args): void must be compatible with Illuminate\Database\Schema\Builder::__call($method, $parameters)

at vendor/laravel-freelancer-nl/aranguent/src/Schema/Builder.php:218
214▕
215▕ /**
216▕ * Silently catch the use of unsupported builder methods.
217▕ */
➜ 218▕ public function __call(string $method, mixed $args): void
219▕ {
220▕ Log::warning("The Aranguent Schema Builder doesn't support method '$method'\n");
221▕ }
222▕ }

  +1 vendor frames

2 [internal]:0
Whoops\Run::handleShutdown()

See if and how we can add an easy to use graph clause to the query builder.
Including collection/graph selection, directions, depth, pruning etc.

What would be a good api?
I'm thinking of adding in a similar way as joins are created in the query builder.
That should let us isolate most graph specific methods.

Index options such as unique and sparse are not automatically included in the index name.

For package compatibility it is probably required to supply an id. ArangoDB uses both _id and _key. Where the latter has a SQL like structure as _id includes the collection.

Common problems and considerations:

• Even though some packages allow you to override the models in use the relationships between them usually don't grab the model's keyname but assume 'id' regardless. This leads to more overriding/overloading than otherwise necessary.
  It's an illusion to think that new and existing packages will all start to grab the key name from the model.
• A model's routeKey falls back to id. _id breaks routes due to the slash in its {collection}/{_key} structure. While the routeKey can be set separately this then leads to problems in other packages that assume the routekey is the id.
• _id must remain available for graph queries
• _key usage is slightly more performant than _id. So preferred by default.
• an id attribute might be nested deeper within a document in which case it should not be convert to _key

All data is stripped in these functions (with $fillable properly set)

Model::create([$request->all()]);
$model->fill([$request->all()]);

Test against popular packages

• barryvdh/laravel-debugbar
• Laravel Horizon
• Spatie Permissions
• Plank Laravel Mediable
• Laravel Jetstream
• Laravel Passport
• Laravel Sanctum
• Spatie Medialibrary
• spatie/laravel-multitenancy
• Cashier Mollie

..->addSelect([ 'id' => 'doc._id', 'published_at' => 'doc.published_at', ])...

returns:

  "doc._id": "collection/12345"
  "doc.published_at": true

Two issues:

1. doc should not be prefixed to the result
2. dot notation isn't handled properly before executing the query

en.attribute incorrectly becomes enDoc.path

$collection->string('token', 64)->unique();
64 is seen as a column.

Expected behaviour:
64 should be ignored