libgraviton / graviton

A Symfony based framework to generate REST services from JSON service definition files.

Graviton

Graviton is a Symfony and Doctrine Mongo ODM based REST server generation toolkit. So it stores all data in MongoDB.

You can define your REST service in an simple JSON format, run the generator - and voilà - your REST API is ready to go.

Let's say you define this file:

{
  "id": "Example",
  "service": {
    "readOnly": false,
    "routerBase": "/example/endpoint/"
  },
  "target": {
    "fields": [
      {
        "name": "id",
        "type": "string"
      },
      {
        "name": "data",
        "type": "string"
      }
    ]
  }
}

Then you run the generator

php bin/console graviton:generate:dynamicbundles

And once running, you will have a full RESTful endpoint at /example/endpoint, supporting GET, POST, PUT, DELETE and PATCH as well as a valid generated JSON schema endpoint, pagination headers (Link as github does it) and much more.

The generated code are static PHP files and configuration for the Serializer and Symfony and is regarded as disposable. You can always regenerate it - don't touch the generated code.

The application is highly optimized for runtime performance, particurarly in the context of PHP-FPM with activated opcache.

It boasts many additional features (such as special validators and many flags and configurations) which are currently mostly undocumented as this project was not built for public usage in mind. But if there is interest and support from outside users, we welcome questions and contributions.

Install

composer install

Usage

./dev-cleanstart.sh

and

php bin/console

Documentation

There are some general docs on interacting with the codebase as a whole.

• Development
• Deploy

Some even broader scoped docs in a seperate repo.

• docs.graviton.scbs.ch

The bundle readme files which show how to interact with the various subsystems.

• DocumentBundle
• FileBundle
• GeneratorBundle
• I18nBundle
• SecurityBundle
• TestBundle
• AnalyticsBundle

And not to forget, the all important CHANGELOG.

Tracing

This component comes with a tracing bundle, but it is deactivated by default. To enable it, one must set this ENVs:

TRACING_ENABLED=true

This enables the bundle. Then you need to set the jaeger-bundle specific envs:

AUXMONEY_OPENTRACING_AGENT_HOST=zipkin-hostname # hostname to jaeger
AUXMONEY_OPENTRACING_AGENT_PORT=6831 # port to jaeger
AUXMONEY_OPENTRACING_SAMPLER_VALUE=true # const sampler value (sends always if true or never if false)

See this and this page about the 2 bundles.

graviton's Issues

Dependabot can't resolve your PHP dependency files

Dependabot can't resolve your PHP dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Dependabot's installed extensions didn't match those required by your application.

Please add the following extensions to the platform config in your composer.json to allow Dependabot to run: ext-mongodb.

The full error raised was:

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - The requested PHP extension ext-mongodb ^1.4.0 is missing from your system. Install or enable PHP's mongodb extension.
  Problem 2
    - alcaeus/mongo-php-adapter 1.1.5 requires ext-mongodb ^1.2.0 -> the requested PHP extension mongodb is missing from your system.
    - alcaeus/mongo-php-adapter 1.1.5 requires ext-mongodb ^1.2.0 -> the requested PHP extension mongodb is missing from your system.
    - Installation request for alcaeus/mongo-php-adapter (locked at 1.1.5, required as ^1.1.5) -> satisfiable by alcaeus/mongo-php-adapter[1.1.5].

  To enable extensions, verify that they are enabled in your .ini files:
    - /etc/php/7.2/cli/php.ini
    - /etc/php/7.2/cli/conf.d/10-opcache.ini
    - /etc/php/7.2/cli/conf.d/10-pdo.ini
    - /etc/php/7.2/cli/conf.d/15-xml.ini
    - /etc/php/7.2/cli/conf.d/20-apcu.ini
    - /etc/php/7.2/cli/conf.d/20-bcmath.ini
    - /etc/php/7.2/cli/conf.d/20-calendar.ini
    - /etc/php/7.2/cli/conf.d/20-ctype.ini
    - /etc/php/7.2/cli/conf.d/20-curl.ini
    - /etc/php/7.2/cli/conf.d/20-dom.ini
    - /etc/php/7.2/cli/conf.d/20-exif.ini
    - /etc/php/7.2/cli/conf.d/20-fileinfo.ini
    - /etc/php/7.2/cli/conf.d/20-ftp.ini
    - /etc/php/7.2/cli/conf.d/20-gd.ini
    - /etc/php/7.2/cli/conf.d/20-gettext.ini
    - /etc/php/7.2/cli/conf.d/20-gmp.ini
    - /etc/php/7.2/cli/conf.d/20-iconv.ini
    - /etc/php/7.2/cli/conf.d/20-igbinary.ini
    - /etc/php/7.2/cli/conf.d/20-imagick.ini
    - /etc/php/7.2/cli/conf.d/20-intl.ini
    - /etc/php/7.2/cli/conf.d/20-json.ini
    - /etc/php/7.2/cli/conf.d/20-ldap.ini
    - /etc/php/7.2/cli/conf.d/20-mbstring.ini
    - /etc/php/7.2/cli/conf.d/20-msgpack.ini
    - /etc/php/7.2/cli/conf.d/20-pdo_sqlite.ini
    - /etc/php/7.2/cli/conf.d/20-phar.ini
    - /etc/php/7.2/cli/conf.d/20-posix.ini
    - /etc/php/7.2/cli/conf.d/20-readline.ini
    - /etc/php/7.2/cli/conf.d/20-redis.ini
    - /etc/php/7.2/cli/conf.d/20-shmop.ini
    - /etc/php/7.2/cli/conf.d/20-simplexml.ini
    - /etc/php/7.2/cli/conf.d/20-soap.ini
    - /etc/php/7.2/cli/conf.d/20-sockets.ini
    - /etc/php/7.2/cli/conf.d/20-sqlite3.ini
    - /etc/php/7.2/cli/conf.d/20-sysvmsg.ini
    - /etc/php/7.2/cli/conf.d/20-sysvsem.ini
    - /etc/php/7.2/cli/conf.d/20-sysvshm.ini
    - /etc/php/7.2/cli/conf.d/20-tokenizer.ini
    - /etc/php/7.2/cli/conf.d/20-wddx.ini
    - /etc/php/7.2/cli/conf.d/20-xdebug.ini
    - /etc/php/7.2/cli/conf.d/20-xmlreader.ini
    - /etc/php/7.2/cli/conf.d/20-xmlwriter.ini
    - /etc/php/7.2/cli/conf.d/20-xsl.ini
    - /etc/php/7.2/cli/conf.d/20-zip.ini
    - /etc/php/7.2/cli/conf.d/25-apcu_bc.ini
    - /etc/php/7.2/cli/conf.d/25-memcached.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Road to 8.0.0

Backward-breaking changes MUST READ THIS!

General changes

• No more JSON schema endpoints and support. All schema information and validation is now based on openapi 3.0.
• All schema locations changed as the format changed to openapi 3.0. New, the global schema is located at /openapi.yaml or /openapi.json. Additionally, each service exposes its schema at /schema[service/endpoint]/openid.[json|yaml]. There is no more item or collection schema as previously, only one schema per service.
• Previously, the /i18n/language service decided which languages are available in Graviton. This service does not exist anymore, the language list is now a parameter. (graviton.translator.languages)
• Properties of type translatable are now generated with the configured language list and are expected to be objects in the MongoDB database.
• The /i18n/translation service does not exist anymore. Anything related to translating of strings in objects during serializing has been removed.

Deployment

• Support for incorporating ENV variables starting with SYMFONY__ is dropped. Those are not parsed anymore.

Service definitions

• schema variations and schema groups (properties onVariation and groups) in service definitions are not supported anymore, no replacement exists.
• the x-dynamic-key feature in service defintions are not supported anymore. You need to remove those. There is no replacement, just define your keys statically.
• Required uniqueness: Within a Graviton instance, the defined service entities need to be uniquely named, the names cannot clash. If non-unique entities are detected, service generation will fail with an error message.
• the collection attribute in extref definitions can only refer to exposed services which have a routerBase. As the routerBase is necessary to build the validation extref, they need to be exposed.

RQL/query changes

• RQL queries on translatable objects are now as-is and passed to MongoDB untouched. before, there were cases where RQL queries on translatable s were changed internally and would match different languages even when only 1 language is passed. this is not done anymore.
• RQL queries on translatable s: if there is a translatable object name, rql queries must now target an property on that object. So the rql query eq(name,string:value) will not match anymore! It must be eq(name.en,string:value).

PHP class changes

• If you have classes that extend RestController: There is no more getResponse() function - just create your own instance. Also, $this->container or getContainer() is not available anymore as this pattern is deperacted. Use dependency injection to inject needed components.

Constraints/validation

• The new validation component does not return all validation errors at once! After the first validation error is detected, it is returned. Subsequent requests may reveal more validation errors.
• Fixed data loss: If an extref field was sent with an URL pointing to a non-existing service, null was inserted in to the database (effectively resulting in a data loss without knowing it). Now if you try to save that, an Exception will be rendered and a Bad Request (status 400) response will be returned.
• Fields that are marked as required: true in the field definition will now be accepted if filled with an empty value for compatible types (like '' for type string)! If you don't want that, you should add the NotNull constraint to your field definition!
• As the entire validation process changed (as is also based on openapi, specifically on the component https://packagist.org/packages/league/openapi-psr7-validator), all validation error messages have changed. Although the response JSON structure remained the same, all the values changed. Please adapt all code that relies on a specific structure and/or wording of the validation errors. These include all validation errors that Graviton displays as responses to POST/PUT/PATCH requests. Note that the schema of the error responses is also included in the openapi documentation.

"Record origin exception" services

(Services, that have a filed with recordOriginException: true in their definition)

• The validation of datetime fields has changed. In order to validate data correctly, you need to send all datetime values in the same timezone you received it. If you change timezone, it will be picked up as a modification and a validation error will be raised if changed on a protected field.

"Versioning" services

(Services, that have versioning: true in service definition)

• If your POST/PUT is rejected because of a wrong version value, the X-Current-Version response header is not returned anymore. Instead, you should re-GET the resource using ?select(version) and use that value.
• Important: If you issue a PATCH request to a versioning: true endpoint and you do not send the version in your PATCH; the existing version in the database is read and validated. Thus, no version check is performed (= it will never complain about a version mismatch).

File (/file) service

• An inconsistency was fixed: Now, Graviton will update the file metadata properties size, filename, hash, mime everytime you upload a new file either to an existing resource or new resource. It follows the simple logic: If the uploaded file is modified, the metadata will be updated.
  Previously, it was not clear when metadata was updated, allowing for uploading files but still supplying own metadata.
  If you want to modify the metadata, just issue a pure Content-type: application/json request to the affected file resource and send your metadata. The metadata will be untouched until a new file is uploaded.
• All the possible ways to interact file the /file service are now clearly outlined in the openapi documentation and it can be (and is) validated against. You can upload files either by a pure data POST, multipart or form-data requests.
• When you update and/or want to set the id of a resource, you must use PUT. If you POST json content with an "id" property in it to /file/, the request will fail.

Queue events (for workers)

• Queue event names sent were changed to reflect the actual action. If you make a request PUT /core/app/example and the record does not already exist, the create event will be published (document.app.app.create on queue) - otherwise the update (document.app.app.update on queue) event will be published.
  Previously, requests to PUT did always cause a update event, even when the entity didn't exist yet.

---

TODO

• all $dm->clear() calls without arguments
• which CompilerPasses can be deleted now in DocumentBundle?
• Fixtures should be generated as services; not using ContainerAwareInterface anymore
• describe the structure of validation errors in the openapi yaml!
• can we delete/remove/refactor the graviton.document.eventmap param? this is generated for a map for event names for EventStatusLinkListener -> if removed, we can also remove param graviton.document.type.extref.mapping
• do we need to specify "nullable": true, in mostly all attributes? what do the tests do if we remove it?
• there is a NotNull constraint, often used in cons bundle - is this asserted in tests? is it still applied?
• there is a testervice definition EmbedTestHashAsEmbedded - it defines subobjects with an exposed id attribute - is this still correctly exposed? should have id in schema of subobjects.
• is there a test that asserts that happens if an extref is sent to a non-existing endpoint?
• cache activated of the openapi request validator?
• what happens if a POST request is made to /core/app but with an existing id in the body? or PUT to a given id with conflicting id in payload?
• change many of the new classes to readonly classes with private properties!
• create an integration test of the important service Graviton\RabbitMqBundle\Controller\StatusUpdateController - is used by worker-base!
• does the setIsUseSecondary setting in QueryService still work? -> is set in RuntimeDefinition but needs to applied
• QueryService is full of side-effects, not clearly scoped!
• Can JSON be stored in '/file` by sending it with another content-type?
• Can Graviton\DocumentBundle\Serializer\Subscriber\DoctrineProxySubscriber be removed?

finalize graviton:generate:resource command

Here are some scripts I have been using to test this:

#!/bin/sh
# generatortest.sh

php app/console graviton:generate:bundle --namespace=Graviton/FooBundle --dir=src --bundle-name=GravitonFooBundle --no-interaction
php app/console graviton:generate:resource --entity=GravitonFooBundle:Bar --format=xml --fields="name:string" --with-repository --no-interaction
php app/console graviton:generate:resource --entity=GravitonFooBundle:Baz --format=xml \
        --fields="name:string isTrue:boolean consultant:Graviton\\PersonBundle\\Document\\Consultant valid:boolean contacts:Graviton\\PersonBundle\\Document\\PersonContact[] tags:array" \
        --with-repository --no-interaction
./vendor/bin/php-cs-fixer fix src/Graviton/FooBundle

#!/bin/sh
# revert-generate.sh

rm -rf src/Graviton/FooBundle
git checkout src/Graviton/CoreBundle/GravitonCoreBundle.php

The code for the generator is in the feature/generator-bundle

Known TODOs:

• implement fields from GravitonFooBundle:Baz above
• add more datatypes (ie. date, ...)
• find some way to test this (e2e)
• implement adding schema info (descriptions, titles, ...) in Resources/config/schema/ (currently @todo are being generated)
• generate validation.xml
• working $ref examples everywhere ;)
• start interfacing with ml3k/gen3 output (Hello Heeeens)

Dependabot can't resolve your PHP dependency files

Dependabot can't resolve your PHP dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Dependabot's installed extensions didn't match those required by your application.

Please add the following extensions to the platform config in your composer.json to allow Dependabot to run: ext-mongodb.

The full error raised was:

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - The requested PHP extension ext-mongodb ^1.4.0 is missing from your system. Install or enable PHP's mongodb extension.
  Problem 2
    - alcaeus/mongo-php-adapter 1.1.5 requires ext-mongodb ^1.2.0 -> the requested PHP extension mongodb is missing from your system.
    - alcaeus/mongo-php-adapter 1.1.5 requires ext-mongodb ^1.2.0 -> the requested PHP extension mongodb is missing from your system.
    - Installation request for alcaeus/mongo-php-adapter (locked at 1.1.5, required as ^1.1.5) -> satisfiable by alcaeus/mongo-php-adapter[1.1.5].

  To enable extensions, verify that they are enabled in your .ini files:
    - /etc/php/7.2/cli/php.ini
    - /etc/php/7.2/cli/conf.d/10-opcache.ini
    - /etc/php/7.2/cli/conf.d/10-pdo.ini
    - /etc/php/7.2/cli/conf.d/15-xml.ini
    - /etc/php/7.2/cli/conf.d/20-bcmath.ini
    - /etc/php/7.2/cli/conf.d/20-calendar.ini
    - /etc/php/7.2/cli/conf.d/20-ctype.ini
    - /etc/php/7.2/cli/conf.d/20-curl.ini
    - /etc/php/7.2/cli/conf.d/20-dom.ini
    - /etc/php/7.2/cli/conf.d/20-exif.ini
    - /etc/php/7.2/cli/conf.d/20-fileinfo.ini
    - /etc/php/7.2/cli/conf.d/20-ftp.ini
    - /etc/php/7.2/cli/conf.d/20-gd.ini
    - /etc/php/7.2/cli/conf.d/20-gettext.ini
    - /etc/php/7.2/cli/conf.d/20-gmp.ini
    - /etc/php/7.2/cli/conf.d/20-iconv.ini
    - /etc/php/7.2/cli/conf.d/20-igbinary.ini
    - /etc/php/7.2/cli/conf.d/20-imagick.ini
    - /etc/php/7.2/cli/conf.d/20-intl.ini
    - /etc/php/7.2/cli/conf.d/20-json.ini
    - /etc/php/7.2/cli/conf.d/20-ldap.ini
    - /etc/php/7.2/cli/conf.d/20-mbstring.ini
    - /etc/php/7.2/cli/conf.d/20-msgpack.ini
    - /etc/php/7.2/cli/conf.d/20-pdo_sqlite.ini
    - /etc/php/7.2/cli/conf.d/20-phar.ini
    - /etc/php/7.2/cli/conf.d/20-posix.ini
    - /etc/php/7.2/cli/conf.d/20-readline.ini
    - /etc/php/7.2/cli/conf.d/20-redis.ini
    - /etc/php/7.2/cli/conf.d/20-shmop.ini
    - /etc/php/7.2/cli/conf.d/20-simplexml.ini
    - /etc/php/7.2/cli/conf.d/20-soap.ini
    - /etc/php/7.2/cli/conf.d/20-sockets.ini
    - /etc/php/7.2/cli/conf.d/20-sqlite3.ini
    - /etc/php/7.2/cli/conf.d/20-sysvmsg.ini
    - /etc/php/7.2/cli/conf.d/20-sysvsem.ini
    - /etc/php/7.2/cli/conf.d/20-sysvshm.ini
    - /etc/php/7.2/cli/conf.d/20-tokenizer.ini
    - /etc/php/7.2/cli/conf.d/20-wddx.ini
    - /etc/php/7.2/cli/conf.d/20-xdebug.ini
    - /etc/php/7.2/cli/conf.d/20-xmlreader.ini
    - /etc/php/7.2/cli/conf.d/20-xmlwriter.ini
    - /etc/php/7.2/cli/conf.d/20-xsl.ini
    - /etc/php/7.2/cli/conf.d/20-zip.ini
    - /etc/php/7.2/cli/conf.d/25-memcached.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

DynamicBundleGenerateCommand: Get mongodb name from config

Mongo db name in Dynamic Bundle generator must be get from Parameter, at the moment it's hard coded..

random unordered tasks

We should move these into GRVs.

• find and implement standardized ways to offer sync capabilities to an offline client
• implement a standardized way for clients to store schemaless data
  • check if a simple key/value store won't fullfill most needs (ie. /core/app/hello/settings/<key>)
  • define a sensible base line for all remaining edge cases (ie. no proprietary blobs in the key/value store and options)
• update documentation with client recommendation for all major platforms (browsers, ios, ...)
• find a way to do i18n right while still allowing an offline client to switch languages
• implement api versions with some semver magic (parse the X-Version header and act accordingly, allow both sides of the comms to specify a version constraint and define behaivour when said constraint is violated)
• implement delayed storing of records (202 Accepted for when backends go missing)
• find a way to store multiple linked documents in an offline client and still allow $ref linking them.
• implement PATCH verb

PHP error in PagingLinkResponseListener

Stack traceL

Warning: strpos() expects parameter 1 to be string, array given
in src/Graviton/RestBundle/Listener/PagingLinkResponseListener.php at line 131
...

In order to submit a Symfony Form, either handleRequest() or submit() should be called (not both)

Where:
https://github.com/libgraviton/graviton/blob/develop/src/Graviton/RestBundle/Controller/RestController.php#L592

Definition:
submit(): Used to manually submit a form (e.g. HTTP method has to be checked manually)
handleRequest(): Handles the form submission automatically (e.g. HTTP method is checked automatically)

see http://symfony.com/doc/current/cookbook/form/direct_submit.html

Wrong:

// ...
$form->handleRequest($request);
$form->submit(json_decode(str_replace('"$ref"', '"ref"', $request->getContent()), true), false);
// ...

Actually, I think Symfony should throw an Exception when calling submit() after handleRequest() was called.

Correct:

// ...
$form->submit(json_decode(str_replace('"$ref"', '"ref"', $request->getContent()), true), false);
// ...

Dependabot can't resolve your PHP dependency files

Dependabot can't resolve your PHP dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Dependabot's installed extensions didn't match those required by your application. Please add the following extensions to the platform config in your composer.json: ext-mongodb.

The full error raised was:

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - The requested PHP extension ext-mongodb ^1.4.0 is missing from your system. Install or enable PHP's mongodb extension.
  Problem 2
    - alcaeus/mongo-php-adapter 1.1.5 requires ext-mongodb ^1.2.0 -> the requested PHP extension mongodb is missing from your system.
    - alcaeus/mongo-php-adapter 1.1.5 requires ext-mongodb ^1.2.0 -> the requested PHP extension mongodb is missing from your system.
    - Installation request for alcaeus/mongo-php-adapter (locked at 1.1.5, required as ^1.1.5) -> satisfiable by alcaeus/mongo-php-adapter[1.1.5].

  To enable extensions, verify that they are enabled in your .ini files:
    - /etc/php/7.2/cli/php.ini
    - /etc/php/7.2/cli/conf.d/10-opcache.ini
    - /etc/php/7.2/cli/conf.d/10-pdo.ini
    - /etc/php/7.2/cli/conf.d/15-xml.ini
    - /etc/php/7.2/cli/conf.d/20-bcmath.ini
    - /etc/php/7.2/cli/conf.d/20-calendar.ini
    - /etc/php/7.2/cli/conf.d/20-ctype.ini
    - /etc/php/7.2/cli/conf.d/20-curl.ini
    - /etc/php/7.2/cli/conf.d/20-dom.ini
    - /etc/php/7.2/cli/conf.d/20-exif.ini
    - /etc/php/7.2/cli/conf.d/20-fileinfo.ini
    - /etc/php/7.2/cli/conf.d/20-ftp.ini
    - /etc/php/7.2/cli/conf.d/20-gd.ini
    - /etc/php/7.2/cli/conf.d/20-gettext.ini
    - /etc/php/7.2/cli/conf.d/20-gmp.ini
    - /etc/php/7.2/cli/conf.d/20-iconv.ini
    - /etc/php/7.2/cli/conf.d/20-igbinary.ini
    - /etc/php/7.2/cli/conf.d/20-imagick.ini
    - /etc/php/7.2/cli/conf.d/20-intl.ini
    - /etc/php/7.2/cli/conf.d/20-json.ini
    - /etc/php/7.2/cli/conf.d/20-ldap.ini
    - /etc/php/7.2/cli/conf.d/20-mbstring.ini
    - /etc/php/7.2/cli/conf.d/20-phar.ini
    - /etc/php/7.2/cli/conf.d/20-posix.ini
    - /etc/php/7.2/cli/conf.d/20-readline.ini
    - /etc/php/7.2/cli/conf.d/20-redis.ini
    - /etc/php/7.2/cli/conf.d/20-shmop.ini
    - /etc/php/7.2/cli/conf.d/20-simplexml.ini
    - /etc/php/7.2/cli/conf.d/20-soap.ini
    - /etc/php/7.2/cli/conf.d/20-sockets.ini
    - /etc/php/7.2/cli/conf.d/20-sysvmsg.ini
    - /etc/php/7.2/cli/conf.d/20-sysvsem.ini
    - /etc/php/7.2/cli/conf.d/20-sysvshm.ini
    - /etc/php/7.2/cli/conf.d/20-tokenizer.ini
    - /etc/php/7.2/cli/conf.d/20-wddx.ini
    - /etc/php/7.2/cli/conf.d/20-xdebug.ini
    - /etc/php/7.2/cli/conf.d/20-xmlreader.ini
    - /etc/php/7.2/cli/conf.d/20-xmlwriter.ini
    - /etc/php/7.2/cli/conf.d/20-xsl.ini
    - /etc/php/7.2/cli/conf.d/20-zip.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

$ref searches in arrays use .. operator while non $ref searches use . operator

I need to get all file resources having a specific $ref within their links array. However, the following request does always return an empty result:

http://graviton-develop.nova.scapp.io/file/?eq(links.%24ref,%2Fcore%2Fapp%2Fadmin)

Same for http://graviton-develop.nova.scapp.io/file/?like(links.%24ref,*).

But when you execute http://graviton-develop.nova.scapp.io/file/?eq(links.type,user), you'll see that these requests should return at least one result.

Do I send wrong requests or is there a bug affecting filtering by $ref within array?