Is it possible like DataTables put in the request limit = -1

for no limit results?

Example:

&limit=-1

So we can avoid: &limit=999999

A bit of documentation for #173 is required!!

These three methods

• BaseRepository::setQueryOptionsFromRequest()
• BaseRepository::setQueryOptionsFromRequestWithCustomFilter()
• BaseRepository::setQueryOptionsFromRequestWithCustomOrFilter()

defines QueryBuilderOptions object with query string variables. Only BaseRepository::setQueryOptionsFromRequest() contains this snippet:

    $requestAttributes = [];
    foreach ($request->attributes->all() as $attributeName => $attributeValue) {
        $requestAttributes[$attributeName] = $request->attributes->get(
            $attributeName,
            $attributeValue
        );
    }

It get all current request variables and pass them to the QueryBuilderOptions. This may cause some problem if a resource that uses the query-bundle require a variable that is not in the list:

        'filtering'   => $filtering,
        'orFiltering' => $filterOrCorrected,
        'limit'       => $limit,
        'page'        => $page,
        'filters'     => $filters,
        'orFilters'   => $filterOrCorrected,
        'sorting'     => $sorting,
        'rel'         => $rel,
        'printing'    => $printing,
        'select'      => $select, 

Create an entity annotation on its fields to declare if that field can't be filtered so if a request try to filter with that field the query bundle remove automatically that filter for example the field password. Now that can be done into the request listener but I think is better to Do it into the entity

It would be nice to have an option to deny access to not-exposed fields while filtering.

I would change the name of the repo in: apiQL-bundle

Instead of return scalar types array, it could be better to return a collection of items. A

In version 1.0.7 were introduces Vocabulary/Operators that contains all operator definitions. But definitions ara still arrays. As developer I would an Operator object. The final purpose of this Object is also to remove $whereCondition string in favour a Objects\WhereCondition object.

We need to add this badge ASAP. But we need to wait that #19 is merged!

Hello everybody,
I would like to cover all the repository with tests.

What do you think top open a Pull request on WIP and split It into different task for every class for example?

It could be interest to integrate travis for CI or some similar tool to do It

Let me know

If you use buildSelectValue from QueryBuilderFactory and you are not set selectIt calls $this->getEntityAliasfunction that doesn't extsts

When inside an url like this:

entities/{id}/someAction

returns this error when is use inside the repository paginateResults() method:

Some mandatory parameters are missing (\"id\") to generate a URL for route \"app_entity_getentity\".",

The solution now is to overwrite the function customQueryStringValues inside the repository like this:

public function customQueryStringValues()
    {
        return['id'];
    }

But It could be better to autodetection url parameters

Is possible to have a single result without pagination?

Example: I need to get a specific record by Id with custom filter not passed by url.

I would like to do something like this:

            $filters['id|eq'] = $id;
            $filters['myCustomFilter|eq] = 'foo';

            $result = $this->getDoctrine()
                ->getRepository('AppBundle:Entity')
                ->setRequestWithFilter($request, $filters)
                ->getResult(); //or find

Remove select getter and setter because select isn't used

Object Queries\Objects\Operator was marked as deprecated in version 2.3. Now should be removed.

Whenever result could be a single item

$filters['id|eq'] = $id;
$entity = $this->getDoctrine()
  ->getRepository('AppBundle:Table')
  ->setRequestWithFilter($request, $filters)
  ->findAllPaginated();

we actually need to intercept response with pagination data and keep just first _embedded value:

$response = $this->createApiResponse($entity, 200)->getContent();

$responseClean = json_decode($response, true);
$content = $responseClean['_embedded']['items'][0];

and finally return the content

return new JsonResponse($content);

When this snippet stops to be "unknown" can be added to readme file ^_^!

[![Code Coverage](https://scrutinizer-ci.com/g/studiomado/query-bundle/badges/coverage.png?b=master)](https://scrutinizer-ci.com/g/studiomado/query-bundle/?branch=master)

Scrutinizer found this line of dead code

https://scrutinizer-ci.com/g/studiomado/query-bundle/inspections/37580868-8fb1-452a-b847-5f5019eb4c6d/issues/files/src/Mado/QueryBundle/Queries/QueryBuilderFactory.php?issueId=22932879

It could be better if a query like

?filtering[bar|op1]=value1&filtering[foo|op2]=value2

could be writeable as

?and[bar|op1]=value1&and[foo|op2]=value2

from query string and as {"and|or": {"bar": {"op1": "value1"},"foo": {"op2": "value2"}}}

{
    "and|or": {
        "bar": {
            "op1": "value1"
        },
        "foo": {
            "op2": "value2"
        }
    }
}

So then we'll query api directly with json.

We also need to add this lines in composer.json file. This fix shows in packagist.org the development version instead of "dev-master". It's important to show what are version(s) in development. Once we've "finished" version 1.0 we can bump to version 1.1 and fix these lines.

"extra": {
    "branch-alias": {
        "dev-master": "1.0-dev"
    }
},

These three methods contains repeated code and looks like factory method that can be moved out from here or simply improved in design.

BaseRepository::setQueryOptionsFromRequest()
BaseRepository::setQueryOptionsFromRequestWithCustomFilter()
BaseRepository::setQueryOptionsFromRequestWithCustomOrFilter()

According to a BC promise, I'll suggest to leave these methods, set them as deprecated (removed in version 2.0), and finally to add new factory here or in a new class for next minor release.

"Minor releases (such as 2.5, 2.6 etc.) may introduce new features, but must do so without breaking the existing API of that release branch (2.x in the previous example)."

This code was inherited from legacy code. Should be removed.

We can add the possibility to return a serialized and standard response with Its relations passed into query string.
Something like getResponse() because when you create a new project you need to copy always the same function to get your correct serialized, standard response.
I mean this code:

protected function createApiResponse($data, $statusCode = 200, $groups = [])
    {
        $requestStack = $this->get('request_stack');
        $serializer = $this->get('jms_serializer');

        $groups = array_merge(['Default'], $groups);
        $groups = array_merge($groups, explode(',', $requestStack->getCurrentRequest()->query->get('rel', 'Default')));
        $groups = array_unique($groups);

        $json = $serializer->serialize(
            $data,
            'json',
            SerializationContext::create()
                ->enableMaxDepthChecks()
                ->setGroups($groups)
        );

        return new Response($json, $statusCode, array(
            'Content-Type' => 'application/json',
        ));
    }

What do you think?

An additional filters can be one of listed in the Dictionary (array_keys(Dictionary::getOperators())). Actually is always 'list' and not accept different values inside Mado\QueryBundle\Queries\Objects\Value::class.

It could be nice to add relation with a method not only from query string

It could be very useful to create a query with more or filter conditions separated like this:

select * from entity WHERE name = 'foo' OR surname = 'baz' OR description = 'bar'  OR subject = 'buzz';

The purpose is to have something like this:

select * from entity WHERE (name = 'foo' OR surname = 'baz') AND (description = 'bar'  OR subject = 'buzz');

Move the responsibility to build the QueryBuilderOptions out from BaseRepository.

Until now we have been worked without care about php version. Starting from v2.2.10 php version is forced to 7.0 because some software works with that version. According to this fact we can still mantains version 2.2 but also develop new version against most recent php71 version.

Two version could be always maintained: 2.2 and master. Each bug found in version 2.2 will be merged to master.

/cc @AlessandroMinoccheri @davidedonattini @mmedelin @simocheccoli @orociscaverai

I would say in the composer.json the dependencies with the other bundles such as: JMS, Doctrine, HATEOS, PagerFanta

Actually QueryBuilderOptions is used for both CLI and HTTP interfaces. It is used mainly in controllers. This means that it must be built within a request. This suggest a "RequestQueryBuilderOption" component. Also, ... a "CLIQueryBuilderOption" should exists. These names are just ideas.

            └── QueryBuilderOptions
                       ├── ...
                       ├── CliOptions
                       └── HttpOptions

This could affect also BaseRepository and all its initializers. We may also have a CliBaseRepository and or HttpBaseRepository?

/cc @orociscaverai @AlessandroMinoccheri

When a filter with null value is passed the query must be change from this:

table.field = NULL

to this:

table.field IS NULL

Is necessary to change inner join to left join when a filter or is applied, because some relations can be null so now there aren't retrieved

see https://scrutinizer-ci.com/g/studiomado/query-bundle/code-structure/master/class/Mado%5CQueryBundle%5CQueries%5CQueryBuilderFactory&issueId=22932879#inspectioncomment-97052142

DijkstraWalker is final. This is ok because we should not overwrite some behavior. But we also need to mock DijkstraWalker. We need an interface that leave DijkstraWalter final but allow us to create mock of a walker.

It would be great that you can use query-bundle with only mysql and not only with MariaDB

see https://scrutinizer-ci.com/g/studiomado/query-bundle/issues/master/files/src/Mado/QueryBundle/Queries/QueryBuilderFactory.php?&issueId=26864748#inspectioncomment-96851444

@AlessandroMinoccheri Are 7.0 and 7.1 php version enough? Are there applications with php version 5.*?

We have more version alive. I suggest to move everything to a new v2.5.0 and keep mantained just this instead of:

• 2.2
• 2.3
• 2.4

main issue here is that earlier versions use php 7.1 or 7.2 features. But this library works also with php 7.0 or older version. Because of it is hard and wasteful to spend time to keep versions maintained together, just one version could be a good solution.

Sorting on 2nd level embedded it crashes

?sorting[_embedded.customer.macrocategory.descrizione_macrocatyegory]=asc

Instead filtering with the same field it works
?filtering[_embedded.customer.macrocategory.descrizione_macrocatyegory|contains]=aaa

ERROR

{"code":500,"message":"[Semantical Error] line 0, col 234 near 'macrocategory': Error: Class GammaBundle\\Entity\\Macrocategory has no field or association named macrocategory"}

LOG

[2018-06-14 09:46:50] request.CRITICAL: Uncaught PHP Exception Doctrine\ORM\Query\QueryException: "[Semantical Error] line 0, col 234 near 'macrocategory': Error: Class GammaBundle\Entity\Macrocategory has no field or association named macrocategory" at /home/vagrant/mt-api/vendor/doctrine/orm/lib/Doctrine/ORM/Query/QueryException.php line 63 {"exception":"[object] (Doctrine\ORM\Query\QueryException(code: 0): [Semantical Error] line 0, col 234 near 'macrocategory': Error: Class GammaBundle\Entity\Macrocategory has no field or association named macrocategory at /home/vagrant/mt-api/vendor/doctrine/orm/lib/Doctrine/ORM/Query/QueryException.php:63, Doctrine\ORM\Query\QueryException(code: 0): SELECT s FROM StockSelloutBundle\Entity\Stock s INNER JOIN s.customer table_customer INNER JOIN table_customer.macrocategory table_macrocategory WHERE s.year = :field_year_827 AND s.week = :field_week_467 ORDER BY table_macrocategory.macrocategory asc at /home/vagrant/mt-api/vendor/doctrine/orm/lib/Doctrine/ORM/Query/QueryException.php:41)"} []

Here we have two kind of filters:

• and
• or

Actually exists setFilters method (for and case) and setOrFilters method (for or case). It could be better if also And filters become explicit.