Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0-ALPHA3
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      There should be a configuration option which specifies the class-name of the collection that will be created. The specified collection should implement the \Doctrine\Common\Collections\Collection interface. A custom collection would be needed if one want's to have some sort of aggregate functions, like 'getSum()' or 'getWeight()' for example.

        Issue Links

          Activity

          Hide
          Roman S. Borschel added a comment -

          You can already use any Collection implementation you like as long as you program to the interface after the entity has become managed (or detached). This is from the manual:

          "Collection-valued persistent fields and properties must be defined in terms of the Doctrine\Common\Collections\Collection interface. The collection implementation type may be used by the application to initialize fields or properties before the entity is made persistent. Once the entity becomes managed (or detached), subsequent access must be through the interface type."

          The only thing that could probably be enhanced is to instantiate custom collection types when reconstituting entities from the database. But remember, even then you must program to the interface, not the concrete implementation, therefore, what you have in mind might not work. Collection implementations are wrapped in a PersistentCollection during runtime for change-tracking/lazy-load. A PersistentCollection supports the Collection interface only.

          I have thought about implementing __call in PersistentCollection to forward unknown method calls to the wrapped instance. However I'm not sure I like that. Doctrine would be unaware of any changes that are made to the collection in those methods, making them rather fragile.

          I hope you get the picture

          Show
          Roman S. Borschel added a comment - You can already use any Collection implementation you like as long as you program to the interface after the entity has become managed (or detached). This is from the manual: "Collection-valued persistent fields and properties must be defined in terms of the Doctrine\Common\Collections\Collection interface. The collection implementation type may be used by the application to initialize fields or properties before the entity is made persistent. Once the entity becomes managed (or detached), subsequent access must be through the interface type." The only thing that could probably be enhanced is to instantiate custom collection types when reconstituting entities from the database. But remember, even then you must program to the interface, not the concrete implementation, therefore, what you have in mind might not work. Collection implementations are wrapped in a PersistentCollection during runtime for change-tracking/lazy-load. A PersistentCollection supports the Collection interface only. I have thought about implementing __call in PersistentCollection to forward unknown method calls to the wrapped instance. However I'm not sure I like that. Doctrine would be unaware of any changes that are made to the collection in those methods, making them rather fragile. I hope you get the picture
          Hide
          Christian Heinrich added a comment -

          I'm currently browsing through some open tickets and I think we could mark this one as invalid / won't fix, as the wrapping is a major feature.

          Show
          Christian Heinrich added a comment - I'm currently browsing through some open tickets and I think we could mark this one as invalid / won't fix, as the wrapping is a major feature.
          Hide
          Benjamin Eberlei added a comment -

          I think this two go hand in hand, if we do the EXTRA_LAZY stuff we could also do this one here.

          Show
          Benjamin Eberlei added a comment - I think this two go hand in hand, if we do the EXTRA_LAZY stuff we could also do this one here.
          Hide
          Benjamin Eberlei added a comment -

          Ok, slightly modified, you can specifiy which persistent collection implementation you want to use for your entities.

          Show
          Benjamin Eberlei added a comment - Ok, slightly modified, you can specifiy which persistent collection implementation you want to use for your entities.
          Hide
          Benjamin Eberlei added a comment -

          This is not necessary anymore with EXTRA_LAZY collections, closing. Allowing to specifiy own collections wouldn't help since most often you also need to touch other parts (UnitOfWork Persisters) so its better for code-maintenance to just not allow this.

          Show
          Benjamin Eberlei added a comment - This is not necessary anymore with EXTRA_LAZY collections, closing. Allowing to specifiy own collections wouldn't help since most often you also need to touch other parts (UnitOfWork Persisters) so its better for code-maintenance to just not allow this.

            People

            • Assignee:
              Roman S. Borschel
              Reporter:
              Ville Väänänen
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: