zfcampus / zf-apigility-doctrine Goto Github PK
View Code? Open in Web Editor NEWDoctrine-enabled services for Apigility
License: BSD 3-Clause "New" or "Revised" License
Doctrine-enabled services for Apigility
License: BSD 3-Clause "New" or "Revised" License
It seems like the event key for the fetchAll method is changed to 'getList.post'.
Not sure which one should be used
Undefined index: objectManager
When trying to create a new service using the api and not providing a objectmanager.
This should be catched in api
Currently this is generated in the config
'zf-rest-doctrine-hydrator' => array(
'DoctrineModule\\Stdlib\\Hydrator\\DoctrineObject' => array(
'entity_class' => 'ZfcUser\\Entity\\User',
'object_manager' => 'doctrine.entitymanager.orm_default',
'by_value' => false,
'strategies' => array(),
),
),
'zf-rest-doctrine-resource' => array(
'test\\V1\\Rest\\User\\UserResource' => array(
'object_manager' => 'doctrine.entitymanager.orm_default',
'hydrator' => 'DoctrineModule\\Stdlib\\Hydrator\\DoctrineObject',
),
),
'zf-apigility' => array(
'db-connected' => array(
'test\\V1\\Rest\\Item\\ItemResource' => array(
'adapter_name' => 'clingr',
'table_name' => 'item',
'hydrator_name' => 'Zend\\Stdlib\\Hydrator\\ArraySerializable',
'controller_service_name' => 'test\\V1\\Rest\\Item\\Controller',
'entity_identifier_name' => 'id',
),
),
),
the output should be changed for consistency
'zf-apigility' => array(
'db-connected' => array(
'test\\V1\\Rest\\Item\\ItemResource' => array(
'adapter_name' => 'clingr',
'table_name' => 'item',
'hydrator_name' => 'Zend\\Stdlib\\Hydrator\\ArraySerializable',
'controller_service_name' => 'test\\V1\\Rest\\Item\\Controller',
'entity_identifier_name' => 'id',
),
),
'doctrine-connected' => array(
'test\\V1\\Rest\\User\\UserResource' => array(
'object_manager' => 'doctrine.entitymanager.orm_default',
'hydrator' => 'DoctrineModule\\Stdlib\\Hydrator\\DoctrineObject',
),
),
),
After some discussion i was told that the hydrator is moved to the zf-hal key
So I was having an issue with this message: Unable to determine entity identifier for object of type \"Db\\Document\\Property\"; no fields matching \"id\""
And after a while, I figured that if you generate multiple entities using the same Hydrator: DoctrineModule\\Stdlib\\Hydrator\\DoctrineObject
then new entries within config aren't created as they have the same name.
I guess from the example in your README.md, you specify a custom Hydrator but for me there's nothing special so I only really want to use the default hydrator.
How can we get around this as it's a key that specifies a particular entity_class like so:
'zf-rest-doctrine-hydrator' => array(
'DoctrineModule\\Stdlib\\Hydrator\\DoctrineObject' => array(
'entity_class' => 'Db\\Document\\Property',
'object_manager' => 'doctrine.documentmanager.odm_default',
'by_value' => false,
'strategies' => array(),
),
),
I guess with the current implementation something the following would work:
'zf-rest-doctrine-hydrator' => array(
'DoctrineModule\\Stdlib\\Hydrator\\DoctrineObject' => array(
'entity_class' => array(
'Db\\Document\\User',
'Db\\Document\\Message',
'Db\\Document\\Property',
),
'object_manager' => 'doctrine.documentmanager.odm_default',
'by_value' => false,
'strategies' => array(),
),
),
Is this a requirement at all since not everyone wants custom hydration?
I have an entity with the following example structure:
{
id: 465
serial: "9110520800531"
created: "2010-02-05T07:29:30Z",
location: {
__isInitialized__: false
},
company: { }
}
Location and company are both a ManyToOne association. I put a fetch="EAGER" on company that caused the { __isInitialized: false } to be replaced with {}. So I think instead of the proxy class it gets actually loaded/fetched. However, in the json output it's still an empty object.
Is support for a ManyToOne association implemented yet, do I have to add a certain strategy? Please point me in the right direction! Thanks!
An api for metadata is needed to fetch object manager metatdata.
I've got relationships like:
Account hasMany Things
When I log the user in, I make a request for his Account and would like his things in one call so I have to have a config like:
return array(
'doctrine-hydrator' => array(
'MyApp\\V1\\Entity\\AccountHydrator' => array(
'entity_class' => 'MyApp\\V1\\Entity\\Account',
'object_manager' => 'doctrine.entitymanager.orm_default',
'by_value' => true,
'use_generated_hydrator' => true,
'strategies' => array(
'monsters' => 'CollectionExtract'
),
),
'MyApp\\V1\\Entity\\ThingHydrator' => array(
'entity_class' => 'MyApp\\V1\\Entity\\Thing',
'object_manager' => 'doctrine.entitymanager.orm_default',
'by_value' => true,
'use_generated_hydrator' => true,
// Has to be CollectionLink or else we get nested exception
'strategies' => array(
'account' => 'CollectionLink'
),
),
),
);
And get the following response from a fetchAll: GET /accounts/me
{
"id": 1,
"name": "Joe Bloggs",
"things": [
{
"id": 1,
"name": "Book",
"account": null
},
{
"id": 2,
"name": "Pencil",
"account": null
}
]
}
All good.... but when I try to create a "Thing" with the following call: POST /things
{
"name": "Clock",
"account": {
"id": 1
}
}
The account is never hydrated because of the CollectionLink on ThingHydrator. If I remove that, I get a nested exception.
I can get around this by removing all of the strategies and making individual calls but it seems eventually I'll end up removing all of my strategies and using the zoom
functionality.
Is there a way around this or perhaps a way for me to specify hydrators depending on the call type? I think POST/Create
shouldn't cause a nested exception.
Requires
php: >=5.4
zfcampus/zf-apigility: dev-master
zfcampus/zf-configuration: dev-master
But there is no zfcampus/zf-configuration: dev-master version and composer install fails
Problem 1
- Installation request for zfcampus/zf-apigility-doctrine dev-master -> satisfiable by zfcampus/zf-apigility-doctrine[dev-master].
- zfcampus/zf-apigility-doctrine dev-master requires zfcampus/zf-configuration dev-master -> no matching package found.
Try to get pagination values into Doctrine Paginator collections
I'm trying to create a resource for my entity (Tasks) and I'm getting code 0 error with message "An exception was raised while creating "Hal"; no instance returned": http://pastebin.com/8ekTqbSZ
I'm making a post request with data:
{
"objectManager": "doctrine.entitymanager.orm_default",
"resourceName": "Tasks",
"entityClass": "RAC\\Entity\\Tasks",
"pageSizeParam": "limit",
"routeIdentifierName": "tasks_id",
"entityIdentifierName": "id",
"routeMatch": "/api/tasks",
"hydratorName": "RAC\\V1\\Rest\\Apps\\Tasks",
"hydrateByValue": true
}
I've also noticed that after post the Apigility admin stops displaying RAC API (name doesn't show at the top anymore).
I was wondering why is this happening, am I doing something wrong?
P.S.: I noticed that in readme.md you provide a wrong package name for installation (hounddog/doctrine-data-fixture-module:0.0.*).
I am not able to update entities without adding
$this->getObjectManager()->persist($entity);
Just wondering if someone else is having this issue. I would throw in a pr for this soon.
Hi can you show me in the right direction to see an example of the doctrine + apigility integration?
Hey,
In my product I get this link to get my categories. (1 product can have multiple categories, 1 category can have multiple products):
links: {
categories: {
href: "http://localhost/api/category?query[0][field]=products&query[0][type]=eq&query[0][value]=1"
}-
}
When I execute the link it will generate a query like this:
SELECT row FROM Entity\Category row WHERE row.products = 1;
this doesn't work... I'm not an expert in doctrine, but this query should work:
SELECT row FROM Entity\Category row JOIN row.products p WHERE p.id = 1;
No the question is: am I doing something wrong, or is this just nog working in zf-apigility-doctrine?
Second question, the other way around, getting a category with the links to the products is not working because you have just one mappedBy side. Is there a way to solve this?
By default all the properties of entities are exposed in the API. Is it an idea to show only properties that are defined as field of the REST service as soon as ONE field is added?
Like to hear your thoughts about this!
I was looking into creating an API route that looks like:
GET /users/:user_id/assets[/:asset_id]
In this example, I want to filter the assets based on the selected user (:user_id).
Can't find a way to make this work. I would rather not use the query parameter for this specific case.
Any thoughts on how to fix this issue?
It should also work for POST, PUT, DELETE, ... So that the user_id is automatically added to the Doctrine Entity or Document.
Additional: It should also work in deeper levels, e.g.
/user/:user_id/directories/:directory_id/assets[/:asset_id]
This would filter assets based on user + directory. a POST will add an asset to a user directory.
So every sub level has it's own route / doctrine resource + collection
Don't really know if this is of any value but i could interesting to complying with the following technologies
I was trying to reuse this for a commandline controller and
Parameters passed to fetchAll are ignored.
On line 164 they are overwritten directly by query parameters.
It would be great if we could use this method by passing our own parameters still.
Steps:
Fatal error: Maximum function nesting level of '100' reached, aborting! in /vagrant/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php on line 815
Call Stack
# Time Memory Function Location
1 0.0061 229800 {main}( ) ../index.php:0
2 0.4173 6709392 Zend\Mvc\Application->run( ) ../index.php:38
3 0.4233 6807496 Zend\EventManager\EventManager->trigger( ???, ???, ???, ??? ) ../Application.php:310
4 0.4233 6807496 Zend\EventManager\EventManager->triggerListeners( ???, ???, ??? ) ../EventManager.php:207
5 0.4234 6809256 call_user_func ( ???, ??? ) ../EventManager.php:468
6 0.4234 6809288 Zend\Mvc\DispatchListener->onDispatch( ??? ) ../EventManager.php:468
7 0.4325 7033560 Zend\Mvc\Controller\AbstractRestfulController->dispatch( ???, ??? ) ../DispatchListener.php:114
8 0.4325 7033608 Zend\Mvc\Controller\AbstractController->dispatch( ???, ??? ) ../AbstractRestfulController.php:300
9 0.4325 7034328 Zend\EventManager\EventManager->trigger( ???, ???, ???, ??? ) ../AbstractController.php:117
10 0.4325 7034328 Zend\EventManager\EventManager->triggerListeners( ???, ???, ??? ) ../EventManager.php:207
11 0.4330 7055128 call_user_func ( ???, ??? ) ../EventManager.php:468
12 0.4330 7055160 ZF\Rest\RestController->onDispatch( ??? ) ../EventManager.php:468
13 0.4331 7055432 Zend\Mvc\Controller\AbstractRestfulController->onDispatch( ??? ) ../RestController.php:293
14 0.4332 7056376 ZF\Rest\RestController->getList( ) ../AbstractRestfulController.php:368
15 0.4423 7292552 Zend\Mvc\Controller\AbstractController->plugin( ???, ??? ) ../RestController.php:506
16 0.4423 7292752 Zend\Mvc\Controller\PluginManager->get( ???, ???, ??? ) ../AbstractController.php:285
17 0.4423 7292800 Zend\ServiceManager\AbstractPluginManager->get( ???, ???, ??? ) ../PluginManager.php:82
18 0.4423 7292752 Zend\ServiceManager\ServiceManager->get( ???, ??? ) ../AbstractPluginManager.php:103
19 0.4423 7293640 Zend\ServiceManager\ServiceManager->create( ??? ) ../ServiceManager.php:504
20 0.4423 7293640 Zend\ServiceManager\ServiceManager->doCreate( ???, ??? ) ../ServiceManager.php:564
21 0.4423 7293688 Zend\ServiceManager\AbstractPluginManager->createFromFactory( ???, ??? ) ../ServiceManager.php:604
22 0.4423 7293952 Zend\ServiceManager\AbstractPluginManager->createServiceViaCallback( ???, ???, ??? ) ../AbstractPluginManager.php:207
23 0.4423 7294088 Zend\ServiceManager\ServiceManager->createServiceViaCallback( ???, ???, ??? ) ../AbstractPluginManager.php:245
24 0.4424 7294416 call_user_func ( ???, ???, ???, ??? ) ../ServiceManager.php:893
25 0.4424 7294456 ZF\Hal\Module->ZF\Hal\{closure}( ???, ???, ??? ) ../ServiceManager.php:893
26 0.4424 7294600 Zend\ServiceManager\AbstractPluginManager->get( ???, ???, ??? ) ../Module.php:101
27 0.4424 7294736 Zend\ServiceManager\ServiceManager->get( ???, ??? ) ../AbstractPluginManager.php:103
28 0.4424 7295624 Zend\ServiceManager\ServiceManager->create( ??? ) ../ServiceManager.php:504
29 0.4424 7295624 Zend\ServiceManager\ServiceManager->doCreate( ???, ??? ) ../ServiceManager.php:564
30 0.4424 7295672 Zend\ServiceManager\AbstractPluginManager->createFromFactory( ???, ??? ) ../ServiceManager.php:604
31 0.4424 7295936 Zend\ServiceManager\AbstractPluginManager->createServiceViaCallback( ???, ???, ??? ) ../AbstractPluginManager.php:207
32 0.4424 7296072 Zend\ServiceManager\ServiceManager->createServiceViaCallback( ???, ???, ??? ) ../AbstractPluginManager.php:245
33 0.4424 7296400 call_user_func ( ???, ???, ???, ??? ) ../ServiceManager.php:893
34 0.4424 7296440 ZF\Hal\Module->ZF\Hal\{closure}( ???, ???, ??? ) ../ServiceManager.php:893
35 0.4434 7322616 Zend\ServiceManager\ServiceManager->get( ???, ??? ) ../Module.php:120
36 0.4434 7323592 Zend\ServiceManager\ServiceManager->create( ??? ) ../ServiceManager.php:504
37 0.4434 7323592 Zend\ServiceManager\ServiceManager->doCreate( ???, ??? ) ../ServiceManager.php:564
38 0.4434 7323640 Zend\ServiceManager\ServiceManager->createFromFactory( ???, ??? ) ../ServiceManager.php:604
39 0.4434 7323640 Zend\ServiceManager\ServiceManager->createServiceViaCallback( ???, ???, ??? ) ../ServiceManager.php:1025
40 0.4434 7324000 call_user_func ( ???, ???, ???, ??? ) ../ServiceManager.php:893
41 0.4434 7324040 ZF\Hal\Module->ZF\Hal\{closure}( ???, ???, ??? ) ../ServiceManager.php:893
42 0.4442 7328256 ZF\Hal\Metadata\MetadataMap->__construct( ???, ??? ) ../Module.php:69
43 0.4442 7328344 ZF\Hal\Metadata\MetadataMap->setMap( ??? ) ../MetadataMap.php:40
44 0.4445 7358576 ZF\Hal\Metadata\Metadata->__construct( ???, ???, ??? ) ../MetadataMap.php:81
45 0.4489 7439440 ZF\Hal\Metadata\Metadata->setHydrator( ??? ) ../Metadata.php:164
46 0.4489 7439632 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../Metadata.php:362
47 0.4490 7440576 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
48 0.4491 7440792 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
49 0.4491 7441096 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
50 0.4492 7441192 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
51 0.4492 7441496 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
52 0.4492 7441592 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
53 0.4492 7441896 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
54 0.4493 7441992 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
55 0.4493 7442296 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
56 0.4493 7442392 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
57 0.4493 7442696 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
58 0.4494 7442792 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
59 0.4494 7443096 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
60 0.4494 7443192 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
61 0.4494 7443496 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
62 0.4495 7443592 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
63 0.4495 7443896 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
64 0.4495 7443992 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
65 0.4495 7444296 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
66 0.4495 7444392 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
67 0.4496 7444696 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
68 0.4496 7444792 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
69 0.4496 7445096 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
70 0.4496 7445192 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
71 0.4496 7445496 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
72 0.4497 7445592 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
73 0.4497 7445896 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
74 0.4497 7445992 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
75 0.4497 7446296 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
76 0.4497 7446392 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
77 0.4497 7446696 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
78 0.4498 7446792 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
79 0.4498 7447096 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
80 0.4498 7447192 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
81 0.4498 7447496 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
82 0.4499 7447592 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
83 0.4499 7447896 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
84 0.4499 7447992 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
85 0.4499 7448296 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
86 0.4499 7448392 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
87 0.4500 7448696 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
88 0.4500 7448792 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
89 0.4500 7449096 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
90 0.4500 7449192 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
91 0.4500 7449496 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
92 0.4500 7449592 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
93 0.4501 7449896 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
94 0.4501 7449992 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
95 0.4502 7450296 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
96 0.4502 7450392 Zend\ServiceManager\ServiceManager->has( ???, ???, ??? ) ../DoctrineHydratorManager.php:27
97 0.4502 7450696 ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorManager->has( ???, ???, ??? ) ../ServiceManager.php:693
98 0.4502 7450840 Zend\ServiceManager\ServiceManager->get( ???, ??? ) ../DoctrineHydratorManager.php:26
99 0.4502 7450936 Zend\ServiceManager\ServiceManager->hasAlias( ??? ) ../ServiceManager.php:477
When splitting up the modules, the namespace of Module.php remained the same for Server and Admin.
In the application config, ZF\Apigility\Doctrine works, but
ZF\Apigility\Doctrine\Server
ZF\Apigility\Doctrine\Admin
don't.
It's a good idea to split those up, so I can add the Admin module to my development environment only.
In the autoload section of composer.json 2 namespaces are added. Shouldn't this be the full namespace of the module only?
currently when creating a rest service without a hydratorName it becomes null.
Instead we could generate a hydratorName.
e.g
modulename: test
resourceName: User
hydratorname: test\V1\Rest\UserHydrator
At the moment, a new query builder is created for the 'fetchAll' method.
In some cases you want to use a specific base query. For example:
A list needs to be filtered based on the permissions of the current authenticated user. You don't want this user id in the query field, because you can change the URL to another user ID.
Maybe it's a good thing to make the 'ApigilityFetchAllQuery' interface configurable. This way, it is easy to provide a custom base query. When no class is configured, there will be a fallback on the ODM or ORM query. (depending on the configured object manager)
The documentation is not clear of where to go after the Installation step. The section that follows it, API Resources, is not obvious to how it is related to installation or configuration. Should the user call those routes to configure the module?
In fact, I'm still unable to use zf-apigility-doctrine since the documentation has no mention on how to use it after installation.
It seems a configuration UI is still pending (#20), but still the documentation should be clear on what is available so far and how to use what is already there.
Since the split-up to server and admin, composer doesn't find the right repository.
Can you add the correct repositories to packagist?
Because modules created for Doctrine require special config params this module must manage creating the module. But better error checking is required to verify duplicates.
At the moment, it is possible to add ACL or RBAC validation tot the controller or to the route.
But what we need at the moment, is the ability to check permissions based on the current entity.
In my specific case:
At the moment there is no way to get to the resource (selected entity) through a listener. To get to this point, I have to overwrite all the DoctrineResource actions.
All the other parameters can be covered by the authenticated user.
I think it is a good idea to add extra ResourceEvents (update.pre, update, post, ...) in the DoctrineResource object. The target will be the DoctrineResource class. This way it is possible to handle permissions on enitty level.
I have some questions about above:
Hey,
In DoctrineResourceFactory you do a loadHydrator. But my hydrator never exists in the servicelocator and therefore it always returns 'null'. Later on, in DoctrineResource it does a getHydrator, when no hydrator is set, it returns the default DoctrineModule\Stdlib\Hydrator\DoctrineObject().
For the expanding collections (still in developmernt) you need the ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydrator ... But I can't find a way to make my hydrators be in instance of DoctrineHydrator...
My hydrators don't 'really' exists..
snippet out of my config:
'zf-hal' => array(
'metadata_map' => array(
'Common\Entity\Snippet' => array(
'identifier_name' => 'id',
'route_name' => 'api.rest.snippet',
'hydrator' => 'API\V1\Rest\Snippet\SnippetHydrator',
),...
'hydrators' => array(
'abstract_factories' => array(
'ZF\Apigility\Doctrine\Server\Hydrator\DoctrineHydratorFactory',
),
),
'service_manager' => array(
'abstract_factories' => array(
'ZF\Apigility\Doctrine\Server\Resource\DoctrineResourceFactory' => 'ZF\Apigility\Doctrine\Server\Resource\DoctrineResourceFactory',
),
'invokables' => array(
'Common\Apigility\Doctrine\Server\Hydrator\Strategy\CollectionLink' => 'Common\Apigility\Doctrine\Server\Hydrator\Strategy\CollectionLink',
),
),
'zf-rest-doctrine-resource' => array(
'API\V1\Rest\Snippet\SnippetResource' => array(
'object_manager' => 'doctrine.entitymanager.orm_default',
'hydrator' => 'API\V1\Rest\Snippet\SnippetResource',
),
Currently i dont know where to find all the parameters that can be passed when using the api.
Please provide a documentation so that we can also help providing the GUI for the admin.
So I have a User like so:
/**
* @ODM\Document
*/
class User
{
/**
* @ODM\Id
*/
private $id;
/**
* @ODM\ReferenceMany(targetDocument="Db\Document\Message", mappedBy="sentBy")
*/
private $messagesSent;
/**
* @ODM\ReferenceMany(targetDocument="Db\Document\Message", mappedBy="receivedBy")
*/
private $messagesReceived;
}
Who can send and receive messages, which are referencing one another using DbRef:
/**
* @ODM\Document
*/
class Message
{
/** @ODM\Id */
private $id;
/** @ODM\Field(type="date") */
private $dateTimeSent;
/** @ODM\Field(type="string") */
private $text;
/** @ODM\ReferenceOne(targetDocument="Db\Document\User", inversedBy="messagesSent") */
private $sentBy;
/** @ODM\ReferenceOne(targetDocument="Db\Document\User", inversedBy="messagesReceived") */
private $receivedBy;
}
The issue I'm having is that when I grab messages or a single message, the sentBy and receivedBy are both NULL in the rest response. The data is there and linking correctly as if I can get it lazily using regular doctrine like: $message->getSentBy()->getId()
Looking at the Hydrator strategies I can see that CollectionExtract is for displaying an embedded list of child nodes and I'm thinking CollectionLink should be for the other way around (referencing the parent), but it's always NULL.
My config looks like:
'zf-hal' => array(
'metadata_map' => array(
'Db\\Document\\User' => array(
'route_identifier_name' => 'user_id',
'entity_identifier_name' => 'id',
'route_name' => 'scanner.rest.user',
'hydrator' => 'Db\\Document\\UserHydrator',
),
'Db\\Document\\Message' => array(
'route_identifier_name' => 'message_id',
'entity_identifier_name' => 'id',
'route_name' => 'scanner.rest.message',
'hydrator' => 'Db\\Document\\MessageHydrator',
),
),
),
'zf-rest-doctrine-hydrator' => array(
'Db\\Document\\UserHydrator' => array(
'entity_class' => 'Db\\Document\\User',
'object_manager' => 'doctrine.documentmanager.odm_default',
'by_value' => false,
'strategies' => array(
'messagesSent' => 'ZF\\Apigility\\Doctrine\\Server\\Hydrator\\Strategy\\CollectionExtract',
'messagesReceived' => 'ZF\\Apigility\\Doctrine\\Server\\Hydrator\\Strategy\\CollectionExtract',
)
),
'Db\\Document\\MessageHydrator' => array(
'entity_class' => 'Db\\Document\\Message',
'object_manager' => 'doctrine.documentmanager.odm_default',
'by_value' => false,
'strategies' => array(
'sentBy' => 'ZF\\Apigility\\Doctrine\\Server\\Hydrator\\Strategy\\CollectionLink',
'receivedBy' => 'ZF\\Apigility\\Doctrine\\Server\\Hydrator\\Strategy\\CollectionLink',
),
),
),
'zf-rest-doctrine-resource' => array(
'Scanner\\V1\\Rest\\User\\UserResource' => array(
'object_manager' => 'doctrine.documentmanager.odm_default',
'hydrator' => 'Db\\Document\\UserHydrator',
),
'Scanner\\V1\\Rest\\Message\\MessageResource' => array(
'object_manager' => 'doctrine.documentmanager.odm_default',
'hydrator' => 'Db\\Document\\MessageHydrator',
),
),
Should I be providing somehting more than just /api/messages to get the parent's IDs or should they just be there? If I dump the response from the ObjectManager get('Entity', $id) the IDs are null, but they're treated as though they're lazy so you have to get it manually.
Page: /apigility/admin/select-entities/
Console error "ReferenceError: $ is not defined"
Javascript is currently not working in this page
I want to make a module but he throws an expection:
Notice: Undefined variable: patchConfig in C:\www\api\vendor\soliantconsulting\soliantconsulting-apigility\src\SoliantConsulting\Apigility\Admin\Controller\AppController.php on line 47
I'm looking for solution to make CRUD API for Doctrine 2. I found the interesting project https://github.com/leedavis81/drest. Do you have plans to make smth similar? Though it's possible to use DREST with ZF2, but I think it would be better to have native tool for Apigility and Doctrine. Also I'm not sure that current release is stable and author will develop and support it later.
P.S. Some explanation about DREST and what I'm looking for: It's not a problem to realize standard CRUD operations, but it's quite difficult to make universal tool for work with relations and custom list/read operations. The most powerful thing about DREST is Exposing Data (http://leedavis81.github.io/drest/docs/exposing-data/) - you can tell server which fields and which relations (recursevly) you want to include into the response while make read/list query. I can't find any finished solution that provides full-featured ORM REST API like DREST. I even can't find it in Java world, though Java is not my best.
I'm not sure if I'm doing something wrong here but I'm trying to include entity relationships ( OneToMany) in the returned JSON.
Currently it just returns null
in the JSON for the relationship, I've tried registering the CollectionExtract
strategy as a service and altered the config to use this strategy for the field but I just encounter:
Fatal error: Maximum function nesting level of '100' reached, aborting!
Call Stack
# Time Memory Function Location
1 0.0005 245416 {main}( ) ../index.php:0
2 0.2630 13870352 Zend\Mvc\Application->run( ) ../index.php:27
3 0.4883 27030680 Zend\Mvc\Application->completeRequest( ) ../Application.php:327
4 0.4883 27030760 Zend\EventManager\EventManager->trigger( ) ../Application.php:352
5 0.4883 27030896 Zend\EventManager\EventManager->triggerListeners( ) ../EventManager.php:207
6 0.4923 27166016 call_user_func ( ) ../EventManager.php:468
7 0.4923 27166360 Zend\Mvc\View\Http\DefaultRenderingStrategy->render( ) ../EventManager.php:468
8 0.4923 27166800 Zend\View\View->render( ) ../DefaultRenderingStrategy.php:102
9 0.4924 27168824 ZF\Hal\View\HalJsonRenderer->render( ) ../View.php:205
10 0.4924 27169184 ZF\Hal\Plugin\Hal->renderEntity( ) ../HalJsonRenderer.php:117
11 0.4925 27172976 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
12 0.4925 27173480 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
13 0.4999 27462792 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
14 0.4999 27462792 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
15 0.5000 27466528 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
16 0.5000 27466528 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
17 0.5002 27474696 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
18 0.5002 27474696 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
19 0.5003 27478416 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
20 0.5003 27478416 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
21 0.5004 27486584 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
22 0.5004 27486584 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
23 0.5005 27490304 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
24 0.5005 27490304 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
25 0.5006 27498472 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
26 0.5006 27498472 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
27 0.5007 27502192 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
28 0.5007 27502192 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
29 0.5008 27510360 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
30 0.5008 27510360 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
31 0.5009 27514080 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
32 0.5009 27514080 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
33 0.5011 27522248 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
34 0.5011 27522248 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
35 0.5011 27525968 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
36 0.5011 27525968 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
37 0.5013 27534136 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
38 0.5013 27534136 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
39 0.5014 27537856 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
40 0.5014 27537856 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
41 0.5015 27546024 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
42 0.5015 27546024 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
43 0.5016 27549744 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
44 0.5016 27549744 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
45 0.5017 27557912 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
46 0.5017 27557912 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
47 0.5018 27561632 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
48 0.5018 27561632 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
49 0.5019 27569800 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
50 0.5019 27569800 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
51 0.5020 27573520 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
52 0.5020 27573520 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
53 0.5022 27581688 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
54 0.5022 27581688 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
55 0.5022 27585408 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
56 0.5022 27585408 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
57 0.5024 27593576 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
58 0.5024 27593576 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
59 0.5025 27597296 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
60 0.5025 27597296 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
61 0.5026 27605464 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
62 0.5026 27605464 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
63 0.5027 27609184 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
64 0.5027 27609184 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
65 0.5028 27617352 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
66 0.5028 27617352 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
67 0.5029 27621072 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
68 0.5029 27621072 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
69 0.5031 27760224 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
70 0.5031 27760224 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
71 0.5032 27763944 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
72 0.5032 27763944 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
73 0.5033 27772112 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
74 0.5033 27772112 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
75 0.5034 27775832 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
76 0.5034 27775832 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
77 0.5036 27784000 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
78 0.5036 27784000 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
79 0.5037 27787720 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
80 0.5037 27787720 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
81 0.5039 27795912 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
82 0.5039 27795912 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
83 0.5040 27799632 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
84 0.5040 27799632 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
85 0.5041 27807800 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
86 0.5041 27807800 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
87 0.5042 27811520 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
88 0.5042 27811520 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
89 0.5044 27819688 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
90 0.5044 27819688 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
91 0.5045 27823408 ZF\Hal\Plugin\Hal->extractEmbeddedCollection( ) ../Hal.php:511
92 0.5045 27823408 ZF\Hal\Plugin\Hal->extractCollection( ) ../Hal.php:986
93 0.5047 27831576 ZF\Hal\Plugin\Hal->extractEmbeddedEntity( ) ../Hal.php:1045
94 0.5047 27831576 ZF\Hal\Plugin\Hal->renderEntity( ) ../Hal.php:965
95 0.5047 27831976 Zend\EventManager\EventManager->trigger( ) ../Hal.php:488
96 0.5047 27832264 Zend\EventManager\EventManager->triggerListeners( ) ../EventManager.php:207
97 0.5047 27834024 call_user_func ( ) ../EventManager.php:468
98 0.5047 27834056 ZF\Apigility\Admin\Module->onRenderEntity( ) ../EventManager.php:468
99 0.5047 27834104 Zend\EventManager\Event->getParam( ) ../Module.php:426
If I disable xdebug to remove the max function nesting limit PHP just runs out of memory:
Fatal error: Allowed memory size of 134217728 bytes exhausted
The relationship should only fetch 3 entities so I don't see why it needs so much memory. Seems like it is stuck in a infinite recursive function call.
What I'm trying to achieve is some JSON like the following:
{
"some_field": "something",
"relationship": [
{
"something": "something"
},
{
"something": "something"
},
{
"something": "something"
}
]
}
Currently I'm not sure if:
I would prefer to not see collections in resources, but the DoctrineEntity hydrator populates them with empty values.
"_embedded":{
"activity":[
{
"name":"At molestiae est quia culpa vel doloribus. Impedit vero rem est et id. Perspiciatis possimus consectetur consequatur. Nisi consequuntur aut saepe voluptate molestiae vitae maxime enim.",
"id":41,
"workflowActivities":{
},
"_embedded":{
"roleType":{
"name":"Totam numquam sed recusandae facilis ipsam culpa magni. Atque molestiae ducimus non blanditiis blanditiis. Eum consequuntur aut esse. Quas illo sint velit illum repellat.",
"id":94,
"activities":{
},
"workflowEvents":{
},
"roles":{
},
"_links":{
I think it would be good to have a Doctrine OAuth2 Adapter. Currently you almost always have to override both the Factory and Adapter in case you have more fields than username
, password
, first_name
and last_name
.
With a Doctrine OAuth2 adapter it means you can just specify your object manager and entities to retrieve whatever you want.
Just creating an issue to contain my PRs that will hopefully follow tonight.
We need a strategy to integrate this module with the admin for Apigility.
I think there should be a "Create Doctrine Resources" button on the
/admin#/api/DbApi/v1/overview
page which routes to /soliant-consulting/apigility/admin
The /soliant-consulting/apigility/admin route should be changed to /admin/doctrine or whatever is most sensible for Angular JS integration.
When sending a patch request with the object_manager it is beeing ignored as of now. Does this mean that we cannot edit all the parameters through the api currently?
currently not extending leading to a lot of duplicated code.
I will provide a pr on this soon.
DoctrineModule\Stdlib\Hydrator\DoctrineObject
There is a placeholder in this module at Server\Hydrator\AbstractHydrator
To implement this a hydrator should be added to each resource which implements the AbstractHydrator?
I've finally got ApigilityDoctrine working but I've noticed that when I make a get request OneToMany column looks like this:
"app": {
"__initializer__": {},
"__cloner__": {},
"__isInitialized__": false
},
Any idea why?
OK,it's weierophinney who asked me to post here.
Since it's lack of documentation and examples on how to use zf-apigility-doctrine, I don't use it really, so I don't know whether it's a good place to place my problem here. Below is the detail of the problem:
I have two entities SchemaType and SchemaProperty, and they have a Many to Many associations to each other.
I query the entity SchemaType with DQL, in the command line, check the DQL using 'vendor/bin/doctrine-module orm:run-dql ...', it returns the object with all the associations loaded properly.
In resouce class, i run the same query and return the query object. In the response json, normal fields filled with right value, but assiaciations' fields all displays empty '[]'.
Hi guys, I am suffering in trying to get a custom function fetchAll for my collections using zf-apigility-doctrine. Can someone give me an example for that? I need a mapper when using Doctrine? Thanks.
We need to add travis support and tests for stability.
For the sake of very complete data about the collection queried an additional HAL attribute must be added called collectionTotal which is a total count of the collection.
Options from #7 (comment)
include "add an event listener on the 'getList.postfetchAll' event".
The event listener sounds like the most appropriate solution and no PR to Apigility should be considered for this enhancement to this use of Apigility.
The DoctrineRestServiceModel registers a hydrator per entity as an invokable, see DoctrineRestServiceModel.php:#L689.
When generating the module the hydrator is never created though. This isn't a problem when in development mode, because the DoctrineHydratorFactory intercepts the request, but when not in development, the abstract factory isn 't available.
I'm not sure, what the exactly the problem here is.
So I've made a CREATE user API call and wanted to validate that an email for my User entity doesn't already exist. Looking through the admin you can define validators for particular fields and use validators like: Zend\Validator\Db\NoRecordExists
. This requires that you have a DB Adapter setup.
So obviously I want to use DoctrineModule\Validator\NoObjectExists
and pass in my doctrine repository instance. The problem is that it needs an actual instance, which won't work so well defined in a factory inside my module.config.php like:
<?php
return array(
'service_manager' => array(
'factories' => array(
'Scanner\\V1\\Rest\\User\\Validator' => function($sm) {
$repository = $sm->get('doctrine.documentmanager.odm_default')->getRepository('Db\\Document\\User');
$factory = new \Zend\InputFilter\Factory;
$inputFilter = $factory->createInputFilter(array(
0 => array(
'name' => 'email',
'required' => true,
'filters' => array(),
'validators' => array(
0 => array(
'name' => 'DoctrineModule\\Validator\\NoObjectExists',
'options' => array(
'object_repository' => $repository,
'fields' => array('email')
),
),
),
),
));
return $inputFilter;
}
),
),
),
It'd be good if within zf-apigility-admin
it would detect you have the doctrine module and allow you to pick the Doctrine validators straight from the admin. This would require some sort of factory that replaces the Db\Document\User
from config with the repository instance.
What do you think?
I was wondering if Apigility Doctrine supports BigInt type? I use it with Doctrine but I can't update the fields via PATCH request, but changing integer works.
I've searched the repository and the only file I found related to types what this one: https://github.com/soliantconsulting/zf-apigility-doctrine/blob/ef5e8df400d74e6918e89955d948d49121039252/src/ZF/Apigility/Doctrine/Server/Collection/Query/FetchAllOdmQuery.php#L48
BigInt doesn't seem to be there, that's why I think is missing. Can you confirm that?
I found myself re-using the abstract hydrator factory in projects without apigility. Maybe it's a good idea to extract this logic into a new module? zf-doctrine-hydrators?
Or maybe we should try to add this to the DoctrineModule project.
When I make a GET request including query (type = eq) pagination doesn't seem to work well. After filtering I get 2 results which are displayed correctly, but I don't think "first" and "last" links should be displayed, since this is the only page for that query.
Here is the response:
{
"count": 2,
"total": 2,
"collectionTotal": 6,
"_links": {
"self": {
"href": "http://localhost:8080/api/tasks?query%5B0%5D%5Bfield%5D=status&query%5B0%5D%5Btype%5D=eq&query%5B0%5D%5Bvalue%5D=1&query%5B1%5D%5Bfield%5D=type&query%5B1%5D%5Btype%5D=eq&query%5B1%5D%5Bvalue%5D=35&page=1"
},
"first": {
"href": "http://localhost:8080/api/tasks?query%5B0%5D%5Bfield%5D=status&query%5B0%5D%5Btype%5D=eq&query%5B0%5D%5Bvalue%5D=1&query%5B1%5D%5Bfield%5D=type&query%5B1%5D%5Btype%5D=eq&query%5B1%5D%5Bvalue%5D=35"
},
"last": {
"href": "http://localhost:8080/api/tasks?query%5B0%5D%5Bfield%5D=status&query%5B0%5D%5Btype%5D=eq&query%5B0%5D%5Bvalue%5D=1&query%5B1%5D%5Bfield%5D=type&query%5B1%5D%5Btype%5D=eq&query%5B1%5D%5Bvalue%5D=35&page=1"
}
},
"_embedded": {
"tasks": [
...
]
},
"page_count": 1,
"page_size": 25,
"total_items": 2
}
Beside that I noticed that "tasks" are displayed under "_embedded" key, is that correct behavior?
EDIT: was thinking now, maybe this is a correct behavior, it's just a bit confusing. If so, please close the issue and sorry for spamming your repository. :$
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.