Doctrine 2 - ORM

Allow to specifiy custom Entity and Collection Persister classes

Details

  • Type: New Feature New Feature
  • Status: In Progress In Progress
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.0-ALPHA4
  • Fix Version/s: 2.x
  • Component/s: ORM
  • Security Level: All
  • Labels:
    None

Description

It should be allowed to overwrite the default persisters for collections and entities. This should go along the lines of Hibernate which allows to set the custom implementations like:

XML:

<entity persister="persisterClass" />
<OneToMany persister="persisterClass" />

Annotation

/**
 * @Entity(persister="persisterClass")
 * @OneToMany(persister="persisterClass")
 */

Issue Links

is referenced by

Improvement - An improvement or enhancement to an existing feature or task. DDC-445 Evaluate possible ways in which stored procedures can be used

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. DDC-699 ProxyFactory: allow to overwrite $_proxyClassTemplate to allow custom criterias during execution of _load()

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Descending order - Click to sort in ascending order
Hide
Permalink
Stefan Kögel added a comment -

Any chance you could add this quickly? I need this feature urgently to complete an extension using a custom persister. Thanks in advance.

Show
Stefan Kögel added a comment - Any chance you could add this quickly? I need this feature urgently to complete an extension using a custom persister. Thanks in advance.
Hide
Permalink
sebastiaan stok added a comment - - edited

Any change seeing this soon? I really need this for a security feature.

What is making this so hard? just adding an setEntityPersister($entityName, $object) should do the trick.
I don't need any fancy stuff, just a way to limit the fields in the SELECT list.

Edit: OK, I'm shot I CAN NOT overwrite the entity manager as the UnitOfWork is private!
Got any other idea?

Show
sebastiaan stok added a comment - - edited Any change seeing this soon? I really need this for a security feature. What is making this so hard? just adding an setEntityPersister($entityName, $object) should do the trick. I don't need any fancy stuff, just a way to limit the fields in the SELECT list. Edit: OK, I'm shot I CAN NOT overwrite the entity manager as the UnitOfWork is private! Got any other idea?
Hide
Permalink
Thomas Rothe added a comment -

Why is it still missing in 2.3? I would require this for an extension that uses its own overridden entity persister and using a custom persister is the solution that you guys recomend for not overriding the entity manager.

Show
Thomas Rothe added a comment - Why is it still missing in 2.3? I would require this for an extension that uses its own overridden entity persister and using a custom persister is the solution that you guys recomend for not overriding the entity manager.
Hide
Permalink
Guilherme Blanco added a comment -

@Adam I refactored all Persisters optimizing their code, but I could not complete the move from SQL string generation to Doctrine\DBAL\Query.
We missed it, yes. I may reschedule for 2.3

Show
Guilherme Blanco added a comment - @Adam I refactored all Persisters optimizing their code, but I could not complete the move from SQL string generation to Doctrine\DBAL\Query. We missed it, yes. I may reschedule for 2.3
Hide
Permalink
Adam Brodziak added a comment -

I might be mistaken, but AFAICS mentioned Persister heavy refactoring did not made through to 2.2 version. Is there any plan to have it in 2.3 or at any later stage?

Show
Adam Brodziak added a comment - I might be mistaken, but AFAICS mentioned Persister heavy refactoring did not made through to 2.2 version. Is there any plan to have it in 2.3 or at any later stage?
Hide
Permalink
Gediminas Morkevicius added a comment -

Just as I thought that first you will want to make a query builder object for all persisters. since now they use plain sql. Thanks for all your work on this

Show
Gediminas Morkevicius added a comment - Just as I thought that first you will want to make a query builder object for all persisters. since now they use plain sql. Thanks for all your work on this
Hide
Permalink
Benjamin Eberlei added a comment -

Yes, that is correct. I dont want to add it as experimental/undocumented feature because people will take it for granted and make us responsible for possible bc breaks.

I will update the target version accordingly.

Sorry for disappointing you, but this feature is fundamentally important at the core of the library. That means we have to get it right and not rush into it.

Show
Benjamin Eberlei added a comment - Yes, that is correct. I dont want to add it as experimental/undocumented feature because people will take it for granted and make us responsible for possible bc breaks. I will update the target version accordingly. Sorry for disappointing you, but this feature is fundamentally important at the core of the library. That means we have to get it right and not rush into it.
Hide
Permalink
Jonas Wouters added a comment -

Does that mean we will not see this feature before 2.2?

Show
Jonas Wouters added a comment - Does that mean we will not see this feature before 2.2?
Hide
Permalink
Benjamin Eberlei added a comment -

This has not been forgotten, but the Persister is due for a heavy refactoring for 2.2 probably, when we will make it use the SQL Query object that we are working on.

So I cannot merge this, because the API will probably break big time.

Show
Benjamin Eberlei added a comment - This has not been forgotten, but the Persister is due for a heavy refactoring for 2.2 probably, when we will make it use the SQL Query object that we are working on. So I cannot merge this, because the API will probably break big time.
Hide
Permalink
Gediminas Morkevicius added a comment -

Is this forgotten? you should merge it since it does not affect any other parts of ORM, this is a great feature

Show
Gediminas Morkevicius added a comment - Is this forgotten? you should merge it since it does not affect any other parts of ORM, this is a great feature
Hide
Permalink
Benjamin Eberlei added a comment -

implemented this in a feature branch for now, it really doesnt touch any other runtime code so maybe we can still merge this before RC1

http://github.com/doctrine/doctrine2/tree/OverridePersisters

Show
Benjamin Eberlei added a comment - implemented this in a feature branch for now, it really doesnt touch any other runtime code so maybe we can still merge this before RC1 http://github.com/doctrine/doctrine2/tree/OverridePersisters
Hide
Permalink
Roman S. Borschel added a comment -

Moved to 2.1 due to lack of time for any larger new features for 2.0.

Show
Roman S. Borschel added a comment - Moved to 2.1 due to lack of time for any larger new features for 2.0.
Hide
Permalink
Roman S. Borschel added a comment -

Pushing back to beta4.

Show
Roman S. Borschel added a comment - Pushing back to beta4.
Hide
Permalink
Roman S. Borschel added a comment -

Rescheduling for beta3.

Show
Roman S. Borschel added a comment - Rescheduling for beta3.

People

  • Assignee:
    Benjamin Eberlei
    Reporter:
    Benjamin Eberlei
Vote (5)
Watch (7)

Dates

  • Created:
    Updated: