Doctrine 1
  1. Doctrine 1
  2. DC-280

Add pre/postHydrateResultSet() events

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Connection, Query, Record
    • Labels:
      None

      Description

      Over the last several weeks I've been working on streamlining the access control logic in the application I'm working on, and I realized that Doctrine's event listeners might be able to help. For more detailed background information take a look at http://groups.google.com:80/group/dallasphp/browse_thread/thread/91e3f107cd611adf ...but here's the problem in a nutshell:

      Since my application's access control logic is all implemented in PHP rather than in the database (i.e., I can't add access control to my queries as a simple WHERE clause), I'm looking for a way to hook into the query process just after the records have been hydrated and actually modify the result set that gets returned, such that only permissible records show up in the final result set.

      Unfortunately, although there are several listener methods that look promising for this, none of them seem to have access to the data being returned. For instance, if I run a custom query via Doctrine_Query::execute(), the postQuery() hook definitely runs ...but it doesn't give me access to anything but the query string itself.

      Since, in some instances (e.g., hydration listeners), the Doctrine_Event object is assigned arbitrary data that the listener can modify, I'm wondering if the same thing couldn't be done more universally?

        Activity

        Adam Jensen created issue -
        Hide
        Jonathan H. Wage added a comment -

        In Doctrine 1.2 you can create custom hydrators. You can extend the core hydrators to remove the data you want? I think that would work.

        Show
        Jonathan H. Wage added a comment - In Doctrine 1.2 you can create custom hydrators. You can extend the core hydrators to remove the data you want? I think that would work.
        Hide
        Adam Jensen added a comment -

        Sure enough, that does the trick!

        There are a couple of downsides, though, that might be worth considering in terms of future development:

        1. It would be nice to be able to specify constructor arguments for the hydrator, so that collaborators can be injected. In my example, the hydrator needs access to the application's access control list object; currently it's simply retrieving it from a global registry, but it would be nice for testing's sake to be able to inject it instead.
        2. It would also be nice to be able to chain multiple hydrators together; that's one reason I was looking at listeners, since they've got that capability already. That approach allows you to keep distinct behavior distinct a lot more easily.

        Ultimately, I'd still kind of like to see another listener method available ...say, preHydrateResultSet() and postHydrateResultSet()? I think that would be a more flexible approach, even though the custom hydrator solution works quite well.

        Thanks!
        Adam

        Show
        Adam Jensen added a comment - Sure enough, that does the trick! There are a couple of downsides, though, that might be worth considering in terms of future development: 1. It would be nice to be able to specify constructor arguments for the hydrator, so that collaborators can be injected. In my example, the hydrator needs access to the application's access control list object; currently it's simply retrieving it from a global registry, but it would be nice for testing's sake to be able to inject it instead. 2. It would also be nice to be able to chain multiple hydrators together; that's one reason I was looking at listeners, since they've got that capability already. That approach allows you to keep distinct behavior distinct a lot more easily. Ultimately, I'd still kind of like to see another listener method available ...say, preHydrateResultSet() and postHydrateResultSet()? I think that would be a more flexible approach, even though the custom hydrator solution works quite well. Thanks! Adam
        Hide
        Jonathan H. Wage added a comment -

        I like the idea. I'll move this to 1.3. I don't think we're gonna have a 1.3 version but if we do, it'll be there.

        Show
        Jonathan H. Wage added a comment - I like the idea. I'll move this to 1.3. I don't think we're gonna have a 1.3 version but if we do, it'll be there.
        Jonathan H. Wage made changes -
        Field Original Value New Value
        Summary Event and record listeners should be able to modify result sets Add pre/postHydrateResultSet() events
        Affects Version/s 1.2.0-BETA3 [ 10040 ]
        Issue Type Improvement [ 4 ] New Feature [ 2 ]
        Fix Version/s 1.3.0 [ 10042 ]
        Hide
        Jonathan H. Wage added a comment -

        We can include this in a 1.2.x release if you would like to provide a patch and some tests. Thanks, Jon

        Show
        Jonathan H. Wage added a comment - We can include this in a 1.2.x release if you would like to provide a patch and some tests. Thanks, Jon
        Jonathan H. Wage made changes -
        Fix Version/s 1.2.2 [ 10047 ]
        Fix Version/s 1.3.0 [ 10042 ]
        Jonathan H. Wage made changes -
        Fix Version/s 1.2.3 [ 10051 ]
        Fix Version/s 1.2.2 [ 10047 ]
        Jonathan H. Wage made changes -
        Fix Version/s 1.2.3 [ 10051 ]

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DC-280, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Adam Jensen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: