zfcampus / zf-apigility-doctrine Goto Github PK

View Code? Open in Web Editor NEW

107.0 107.0 51.0 1.28 MB

Doctrine-enabled services for Apigility

License: BSD 3-Clause "New" or "Revised" License

PHP 98.17% HTML 1.83%

zf-apigility-doctrine's People

Contributors

Stargazers

Watchers

zf-apigility-doctrine's Issues

Post fetchAll trigger doesn't get triggered

It seems like the event key for the fetchAll method is changed to 'getList.post'.
Not sure which one should be used

getList.post
getList.postFetchAll

Api Undefined index: objectManager

Undefined index: objectManager

When trying to create a new service using the api and not providing a objectmanager.

This should be catched in api

Move config Array to zf-apigility

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

cc @weierophinney

Only one hydrator created when the same instance is used for many entities

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?

Are ManyToOne associations supported yet?

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!

doctrine-metadata api

An api for metadata is needed to fetch object manager metatdata.

Different Hydration depending on Request type

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.

Fails install becouse require zfcampus/zf-configuration: dev-master

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.

Add pagination _embed links back into collections

Try to get pagination values into Doctrine Paginator collections

Resource Creation Problem

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.*).

Persisting Updates

I am not able to update entities without adding
$this->getObjectManager()->persist($entity);

to https://github.com/zfcampus/zf-apigility-doctrine/blob/master/src/Server/Resource/DoctrineResource.php#L284

Just wondering if someone else is having this issue. I would throw in a pr for this soon.

Example

Hi can you show me in the right direction to see an example of the doctrine + apigility integration?

CollectionLink calls getId() which doesn't work with by_value = false

https://github.com/soliantconsulting/soliantconsulting-apigility/blob/master/src/SoliantConsulting/Apigility/Server/Hydrator/Strategy/CollectionLink.php#L50

many2many relations

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?

Show only entity properties that are defined as field in Apigility

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!

Filter based on URL parameter

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

serviceName has replaced resourceName - NewRestServiceEntity.php

https://github.com/StukiOrg/RollnApi/issues/2

@jcarlallen

Support opendata.org/breeze.js

Don't really know if this is of any value but i could interesting to complying with the following technologies

http://www.breezejs.com/home
http://www.odata.org/

DoctrineResource fetchAll method parameters unused

I was trying to reuse this for a commandline controller and
Parameters passed to fetchAll are ignored.

https://github.com/zfcampus/zf-apigility-doctrine/blob/master/src/Server/Resource/DoctrineResource.php#L161

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.

Infinite recursion in HydratorManager

Steps:

Installed using composer.
Added to development.config.php.
Noticed my Apigility modules were not loading in admin.
Visited http://:server:/admin/api/module/:moduleName:/doctrine
Infinite recursion as follows:

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

Module namespace incorrect

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?

Generate Hydrator name

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

Providing a base query for the fetchAll method

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)

Documentation is not clear after Installation

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.

Packagist

Since the split-up to server and admin, composer doesn't find the right repository.
Can you add the correct repositories to packagist?

Add better error checking on module creation

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.

Permissions integration

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:

the authenticated user is in one or more user-groups
the roles are the user-groups
the permissions are variable and based on the selected userGroup
the resource is the entity that is being updated, edited, deleted

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:

What do you guys think about this solution?
Are there any plans to add advanced permission checks to apigility?

Expanding Collections: hydrator

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',
        ),

Docmentation on API

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.

Receiving parents (or at least their IDs)

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.

Error on Page /apigility/admin/select-entities/

Page: /apigility/admin/select-entities/

Console error "ReferenceError: $ is not defined"

Javascript is currently not working in this page

undefined variable $patchConfig

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

Future plans and exposing data

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.

Including Doctrine Entity Relationships in returned JSON

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:

This is even possible
If I am doing something wrong
Or if there is some bug

Collections in resources are empty

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":{

Doctrine OAuth2 Adapter

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.

Integration with zfcampus/zf-apigility-admin

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.

Change object manager

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?

DoctrineRestServiceEntity should extend RestServiceEntity

currently not extending leading to a lot of duplicated code.
I will provide a pr on this soon.

Implement DoctrineObject Hydrator Support

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?

GET response doesn't show unidirectional ManyToOnes

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?

Associations not load in Doctrine Entities

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 '[]'.

werepa commented yesterday at 7:57am

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.

zfcampus/zf-apigility#10 (comment)

Integrate Travis

We need to add travis support and tests for stability.

Collections should include collectionTotal

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.

Entityhydrators are registered as invokables, but not created

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.

Doctrine Validators (ObjectExists, NoObjectExists) and integrating into the admin

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?

BigInt Support?

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?

Move hydrator logica to separate repo

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.

Querying and _links

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. :$

zfcampus / zf-apigility-doctrine Goto Github PK

zf-apigility-doctrine's People

Contributors

Stargazers

Watchers

Forkers

zf-apigility-doctrine's Issues

Recommend Projects

Recommend Topics

Recommend Org