[DCOM-74] Ideas for Event Manager Improvements Created: 31/Oct/11 Updated: 06/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Johannes Schmitt | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
I have two ideas for improving the event manager. 1. Add a lazy-loading implementation as we discussed on IRC already (helpful for keeping the overhead of post generation schema listener down for example) |
| Comments |
| Comment by Guilherme Blanco [ 16/Jan/12 ] |
|
I'm still a huge fan of DOM2 Events. I even have the code somewhere here, but that would break BC. |
| Comment by Marijn Huizendveld [ 06/Feb/13 ] |
|
Would you care to elaborate on your DOM2 Events implementation Guilherme? |
[DCOM-73] CodeGeneration using Doctrine\Common\Persistence\Mapping\ObjectMetadata Created: 24/Oct/11 Updated: 16/Feb/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.3 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Currently we have tons of code in the ODM/ORMs regarding code generation that are ugly to extend and maintain. We should extract all them into a new component, for example named: doctrine-code-generator
|
[DCOM-67] Introduce immutable DateTime with __toString() Created: 27/Aug/11 Updated: 29/Jan/12 |
|
| Status: | Reopened |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Comments |
| Comment by Benjamin Eberlei [ 27/Aug/11 ] |
|
Implemented |
| Comment by Koji Ando [ 11/Jan/12 ] |
|
Though it is implemented once on https://github.com/doctrine/common/commit/7140ad3ba0ba2a94238976dd7f310ff92b478c96, I think this issue must be reopened. |
| Comment by Benjamin Eberlei [ 11/Jan/12 ] |
|
Code was removed due to implementation problems. |
[DCOM-131] [GH-210] MappingDriverChain::getAllClassNames should load all classes from the defaultDriver Created: 27/Oct/12 Updated: 27/Oct/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of rnijveld: Url: https://github.com/doctrine/common/pull/210 Message: I actually tried working around this by adding a driver using an empty string as the namespace, only to find out that `strpos()` doesn't accept an empty delimiter. Anyway, this makes sure that all loadable classes for the defaultDriver are actually returned by MappingDriverChain as well. |
[DCOM-121] [GH-198] [DCOM-118] fix for issue #195 Created: 03/Oct/12 Updated: 03/Oct/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of pscheit: Url: https://github.com/doctrine/common/pull/198 Message: I'm sorry, i have no idea why i got here now 23 commits .. i tried but no success. |
[DCOM-118] [GH-195] Add failing test to demonstrate parse error when @ is present in the description Created: 02/Oct/12 Updated: 03/Oct/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Seldaek: Url: https://github.com/doctrine/common/pull/195 Message: If someone can take this and fix the issue it'd be great. I couldn't figure it out at a quick glance and I don't really have time, but it's a pretty messed up bug and not so trivial to debug if you don't know what happens in the background so I'd say it's pretty important. |
| Comments |
| Comment by Philipp Scheit [ 02/Oct/12 ] |
|
I digged a little deeper. The test case is a great one
o@example.com"
* }
*
* @AnnotationTargetPropertyMethod("Bar")
So that the catchable pattern: ("(?:[^"]|"")*") matches here to greedy (it matches string in quotes):
"
* }
*
* @AnnotationTargetPropertyMethod("
As a result the lexer does not catch the correct @ from the Annotation I could not think of a fast fix for this. But maybe tomorrow. Its not a workaround to do more or less cutting in the parser, because not-well-formed quoted strings would break anyway |
| Comment by Philipp Scheit [ 03/Oct/12 ] |
|
can someone think of a case, where a string (in some annotation) has a newline in it? Otherwise the tests do not fail, when I leave the string matching pattern with a newline.
but the second is not solvable with the lexer itself and would transfer the quoted string matching to the parser, because it needs context. I'll let seldaek pull, what I have (is this the right way?) |
[DCOM-104] Dump() has side-effects or is unreliable Created: 02/Aug/12 Updated: 11/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Vogt | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Debian Squeeze, MySQL 5 |
||
| Description |
|
after setting a one-to-one bi-directional relationship, I am hunting a bug and trying this: \Doctrine\Common\Util\Debug::Dump($this->lord, 1); The first Dump() shows $this->lord as being NULL. |
| Comments |
| Comment by Tom Vogt [ 02/Aug/12 ] |
|
More analysis found the issue being caused by an overloaded setLord() method: public function setLord($NewLord) { return $this; without the marked line, everything works as expected, but of course the inverse side doesn't get updated without it. |
| Comment by Tom Vogt [ 02/Aug/12 ] |
|
it ate the newlines in the comment above. The problematic line is: $this->lord->setFief(null); i.e. the update of the inverse side. |
| Comment by Christophe Coevoet [ 07/Aug/12 ] |
|
I confirm that the dump command has some side effects. It initializes the persistent collections too |
| Comment by Tom Vogt [ 11/Jan/13 ] |
|
Could this for the time being be fixed with a notice in the documentation warning of possible side-effects of Dump() ? |
[DCOM-92] CouchDB, MongoDB caches Created: 25/Dec/11 Updated: 25/Dec/11 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Very simple persisntent caches for query/view results now that result cache is actually useful |
[DCOM-80] Add common exceptions into Doctrine\Common Created: 19/Nov/11 Updated: 20/Dec/11 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Following the ZF and SF2 Standard for Exceptions we should have base exceptions in Common |
[DCOM-77] add a method to force removal of any unmapped data on flush for a given object Created: 16/Nov/11 Updated: 16/Nov/11 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Lukas Kahwe | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
in order to ensure that any unmapped fields are set to their defaults or removed in the case of nosql right now there is no way to do this except with 2 flush calls: aka remove+flush, persist+flush there should be some way to do this in one flush |
[DCOM-102] Updates for Fedora packaging Created: 07/Jul/12 Updated: 24/Nov/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Shawn Iwinski | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
PEAR, Fedora, RHEL |
||
| Description |
|
I am packaging the DoctrineDBAL PEAR package for Fedora and would like to have the following updates:
|
[DCOM-163] [GH-245] Documentation fixes Created: 20/Jan/13 Updated: 20/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of BenMorel: Url: https://github.com/doctrine/common/pull/245 Message: Documentation fixes, continuing the work done on [ORM](https://github.com/doctrine/doctrine2/pull/528) and [DBAL](https://github.com/doctrine/dbal/pull/243).
|
[DCOM-162] [GH-244] return parameter for debug method Created: 14/Jan/13 Updated: 14/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of sethunath: Url: https://github.com/doctrine/common/pull/244 Message: Added $return as 4th parameter to specify whether to return the debug text or print it. It works similar to print_r function |
[DCOM-161] [GH-243] Update composer.json Created: 11/Jan/13 Updated: 11/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of stloyd: Url: https://github.com/doctrine/common/pull/243 Message: Add `provide` part as `doctrine/common` >=2.2,<2.4 has cache in it. |
[DCOM-160] [GH-242] adds a simple manager registry Created: 10/Jan/13 Updated: 10/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of schmittjoh: Url: https://github.com/doctrine/common/pull/242 Message: This registry adds some sane defaults and just requires a simple callable to be fully functional. |
[DCOM-151] [GH-233] [DocParser] Fix trying include classes if its must be ignored. Created: 10/Dec/12 Updated: 10/Dec/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Stroitel: Url: https://github.com/doctrine/common/pull/233 Message: I recreate pull request (add test). Without fix test is failure. |
[DCOM-138] [GH-219] BC breaking constant name fix Created: 16/Nov/12 Updated: 16/Nov/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of jakoch: Url: https://github.com/doctrine/common/pull/219 Message: fixed typo on constant name (STATS_MEMORY_AVAILIABLE => STATS_MEMORY_AVAILABLE) |
[DCOM-184] [GH-266] Add a new method to use a filter before extracting the metadata Created: 12/Mar/13 Updated: 12/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of nicolasTheodo: Url: https://github.com/doctrine/common/pull/266 Message: Hi I have notice that, when you use the doctrine:mapping:convert and doctrine:mapping:import command in symfony, the filter is added after all the metadata are extracting from the database. I have also made a pull-request into the doctrineBundle and doctrine2 to fix this issue. What are your thought about my issue? |
[DCOM-185] DQL errors when attempting to use GROUP BY MAX(field) Created: 26/Mar/13 Updated: 26/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Jon Langevin | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql, groupby, max | ||
| Description |
|
Attempting to run DQL similar to: Throws error: Per docs, MAX is allowed within GROUP BY: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#aggregate-functions If this error is due to some omission on my part, then perhaps the docs should be extended to show a valid GROUP BY MAX() usage, or the error message expanded for a better hint. |
[DCOM-186] [GH-269] ProxyGenerator eval() proxy code when $autoGenerate is true Created: 28/Mar/13 Updated: 28/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of mnapoli: Url: https://github.com/doctrine/common/pull/269 Message: ProxyGenerator eval() proxy code instead of writing it to disk when $autoGenerate is true. Related to DDC-2210(http://www.doctrine-project.org/jira/browse/DDC-2210) The idea of eval() the proxy code was suggested by @ocramius in response to the fact that in dev environment, concurrent file writes create errors. This would also simplify the setup for a dev environment: no more proxy directory to create and make writeable. |
[DCOM-187] [GH-270] Allow empty arrays in annotations Created: 29/Mar/13 Updated: 29/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of kitsunet: Url: https://github.com/doctrine/common/pull/270 Message: an empty array so far is impossible as it either results in a parse error if you just do the obvious {} or if you try {""}it will create an empty entry which in turn will cause errors depending on the annotation. |
[DCOM-152] [GH-234] Criteria filtering doesn't work with DateTime instance Created: 17/Dec/12 Updated: 30/Apr/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of ludekstepan: Url: https://github.com/doctrine/common/pull/234 Message: Filtering associations doesn't work with DateTime instance as a comparison value because filtering uses === operator. It works with SQL backed filtering, but not on PHP collection level. ```php |
[DCOM-189] Doctrine Proxies may conflict with interfaced constructors Created: 03/May/13 Updated: 03/May/13 |
|
| Status: | Reopened |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Documentation | Priority: | Major |
| Reporter: | Harmen M | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The Doctrine ProxyGenerator generates for a proxy a constructor. The documentation of Doctrine states that the constructor is never called. For a project, I created a group of entities with a interfaced constructor in order to enforce a common interface. This results in a incompatible proxy and so a fatal error. |
| Comments |
| Comment by Marco Pivetta [ 03/May/13 ] |
|
Cannot fix this - the constructor is required to override instantiation logic |
| Comment by Harmen M [ 03/May/13 ] |
|
Edit: added the correct description. I accidentially submitted the form before editing the description. |
| Comment by Marco Pivetta [ 03/May/13 ] |
|
Harmen M why do you have a constructor in an interface? That's a very bad practice, and it makes things quite hard to handle. I can think of a workaround, but I first want to be sure there's a real advantage in changing the current implementation to use unserialize() just to handle this specific use case. |
| Comment by Benjamin Eberlei [ 03/May/13 ] |
|
Adding __construct to an interface is an anti pattern and shouldn't be done. |
| Comment by Harmen M [ 03/May/13 ] |
|
Ok, then I change my implementation. But, maybe it is an idea to update the documentation of the ORM and state that constructor interfacing is not possible? |
[DCOM-195] [GH-277] graceful classloader Created: 04/Jun/13 Updated: 04/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Tim-Erwin: Url: https://github.com/doctrine/common/pull/277 Message: Right now if the Doctrine class loader is asked to load a class that it is actually not responsible for (because my class loader is later in the list) it fails with a fatal error. This patch only requires a file if it exists. Other class loaders in the list can still try to load the class. |
[DCOM-199] [GH-282] Fixing failing test Created: 11/Jun/13 Updated: 11/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of nonlux: Url: https://github.com/doctrine/common/pull/282 Message: This fix https://github.com/doctrine/common/commit/a111f1c18d833d4c7a12a3ea059a022f5363e188 for 2.2 branch |
[DCOM-175] Proxies return private properties in __sleep, which is not supported by PHP. Created: 27/Mar/12 Updated: 19/Jun/13 |
|
| Status: | In Progress |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | 2.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Ryan Mauger | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
__sleep should not return private parent property names (see http://php.net/__sleep) this raises notices, and also results in the value of the property being 'N' (null) instead of keeping its value. I am unfortunately stuck having to serialize proxies in my revision tracking, as doctrine seems to be currently ignoring the fetch="EAGER" I set on the related properties. Proxies should use the Serializable interface, and not __sleep, or not return parent property names which are private, it serves no purpose, and is not supported by PHP itself anyway. Also, if you keep __sleep, but do not return the parent property names, then it will only include the items you return, so it would be better to simply drop the __sleep method, I cannot actually see any useful purpose it serves. |
| Comments |
| Comment by Ryan Mauger [ 27/Mar/12 ] |
|
just updated the issue body, realised that I worded something badly. |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
Ryan Mauger I think that's a limitation we have. We use `__sleep` to avoid serializing fields like the initializers and the persisters of course. Even by implementing serializable, it would only work if the end user implemented it in the parent class. Tempted to mark it as "can't fix" |
| Comment by Marco Pivetta [ 24/Jan/13 ] |
|
I think there's a solution by having something like following: class SomeGeneratedProxyName extends RealName implements \Serializable { public function unserialize($data) { $reflectionClass = new ReflectionClass($this); foreach ($reflectionClass->getProperties(ReflectionProperty::IS_PRIVATE) as $privateProp) { $privateProp->setAccessible(true); $privateProp->setValue($this, $data[$privateProp->getName()]); } // ... other props ... } public function serialize() { $data = array(); $reflectionClass = new ReflectionClass($this); foreach ($reflectionClass->getProperties(ReflectionProperty::IS_PRIVATE) as $privateProp) { $privateProp->setAccessible(true); $data[$privateProp->getName()] = $privateProp->getValue($this); } // ... other props ... return $data; } } |
| Comment by Marco Pivetta [ 23/Feb/13 ] |
|
Ryan Mauger I started implementing this one at https://github.com/Ocramius/common/compare/hotfix;DCOM-175 and so far it looks promising. The only doubts so far are with handling cases like following: class MyEntity implements Serializable { public function serialize() { // [...] } public function unserialize($serialized) { // [...] } public function __sleep() { // [...] } public function __wakeup() { // [...] } } So far I didn't get to write tests that demonstrate the exact behaviour for this case, but it looks like when `Serializable` is implemented, `_sleep` and `_wakeup` are ignored. Any thoughts on this? |
| Comment by Marco Pivetta [ 19/Apr/13 ] |
|
A possible solution is to use something like http://eval.in/16806, and thus exploiting the ability of php to retrieve an object's private properties by using the special chr(0) . 'Foo' . chr(0) . 'bar' trick. This can be abstracted by using array_keys((array) $object); , which retrieves also those special keys |
| Comment by Marco Pivetta [ 19/Jun/13 ] |
|
Provided a fix at https://github.com/doctrine/common/pull/284 |
[DCOM-200] [GH-283] Add a test on the ReflexionClass to call implementsInterface on an interface Created: 18/Jun/13 Updated: 18/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of manuquentin: Url: https://github.com/doctrine/common/pull/283 Message: |
[DCOM-28] Extract Common Persistance Interfaces Created: 13/Oct/10 Updated: 30/Jul/11 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Benjamin Eberlei | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
I discussed this with jwage on symfony day cologne and this also came up during discussions with @dzuelke at IPC yesterday. So i hacked up a first patch for discussion that adds a Doctrine\Common\Persistance namespace and extracts the functionality all our 3 layers implement with regards to EntityManager/EntityRepository (and equivalents). Additionally i think it might make sense to also add an interface "ObjectMetadata" that has several getters-only that allow access to the field, identifier and association mapping information. This stuff is not necessarly compatible across layers when returned as its "array" representation, but for libraries hooking into the metadata (symfony admin generator) this might not even be necessary. |
| Comments |
| Comment by Jonathan H. Wage [ 15/Feb/11 ] |
|
Added the interfaces here https://github.com/doctrine/common/commit/59e6b8c6edcb271622923035b687a063c2b47ce8 I implemented them here in the mongodb-odm https://github.com/doctrine/mongodb-odm/commit/8d02e8439fb6737de1e23e1953a643858a8a6c68 and the ORM https://github.com/doctrine/doctrine2/commit/68a40996841b1dbec3b8de5c1038809e5db512b7 I think we can add a few more methods to ClassMetadata interface that are always gonna exist between the different persistence layers. Let me know what you think and what you want to add. |
| Comment by Guilherme Blanco [ 15/Feb/11 ] |
|
Jon is working on this. |
| Comment by Lukas Kahwe [ 19/Mar/11 ] |
|
CouchDB ODM also has DocumentRepositry::findMany(array $ids) |
| Comment by Benjamin Eberlei [ 19/Mar/11 ] |
|
No, that method is only on the repository because CouchDB doesn't need persisters (yet). Its not part of the interfaceable public methods. |
| Comment by Lukas Kahwe [ 19/Mar/11 ] |
|
Not sure I understand. The method is used in DocumentRepository::findBy() as well as in PersistentIdsCollection::load. Seems unnecessary for that method to be public just for this. At any rate imho the method seems convenient and also allows for more efficient access in many RDBMS compared to the generic findBy($criteria) method. So it seems worthwhile adding it. |
| Comment by Benjamin Eberlei [ 20/Mar/11 ] |
|
It doesn't matter what CouchDB uses internally on the DocumentRepository, i don't think this method is particularly useful in another context than CouchDBs use of Collections. In any case the method is just a proxy for findBy(array("id" => array(1, 2, 3, 4, 5, 6))); and i am not sure we need such a method on an interface just for convenience, Repository::find() use-case is much broader. |
| Comment by Lukas Kahwe [ 20/Mar/11 ] |
|
Actually using findMany($ids) ias clearly more efficient in CouchDB than using findBy(array("id" => $ids)); |
| Comment by Benjamin Eberlei [ 20/Mar/11 ] |
|
Hm, you might be right. Ok, this should be included. What i am still pondering with is adding array $orderBy and $firstResult, $maxResults to findOneBy() and findBy() and findAll(). @Jon: Would this be possible for MongoDB? It would not be possible for all use-cases in CouchDB, but for some it can work. |
| Comment by Lukas Kahwe [ 20/Mar/11 ] |
|
Just a super trivial pull to add this to the interface: |
| Comment by Lukas Kahwe [ 21/Mar/11 ] |
|
also wondering if we want to include the idgenerator API in the interface? |
| Comment by Benjamin Eberlei [ 21/Mar/11 ] |
|
Hm yes, i think that is necessary. At least the differentation between assigned and auto-generated ids is relevant for metadata queries. |
| Comment by Jonathan H. Wage [ 21/Mar/11 ] |
|
Yes, findMany() is possible with MongoDB. I think it would just be a proxy to: public function findMany(array $ids) { return $this->findBy(array('_id' => array('$in' => $ids))); } |
| Comment by Benjamin Eberlei [ 21/Mar/11 ] |
|
Hm, What is this syntax? This is not conforming to the EntityRepository interface. The only two allowed methods are: IN Query: $ids = array(...);
findBy(array('_id' => $ids));
Equals = Query: $ids = 1234;
findBy(array('_id' => $id));
Everything else is not portable accross implementations and should only be able through DocumentManager::CreateQuery* sort of apis. |
| Comment by Jonathan H. Wage [ 21/Mar/11 ] |
|
To find by things in MongoDB you just give an array of key => value pairs. It gets passed straight through to MongoDB. The $in syntax is just soemthing mongodb supports. It's not anything specific to Doctrine. |
| Comment by Lukas Kahwe [ 30/Jul/11 ] |
|
i want to heat this topic back up:
|
[DCOM-129] Annotation parser matches colon after annotation Created: 21/Oct/12 Updated: 21/Oct/12 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Konstantin | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Code /** * Removes given $node from the tree and reparents its descendants * * @todo may be improved, to issue single query on reparenting * @param object $node * @throws RuntimeException - if something fails in transaction * @return void */ public function removeFromTree($node) { fails with `[Semantical Error] The annotation "@todo:" in method Gedmo\Tree\Entity\Repository\ClosureTreeRepository::removeFromTree() was never imported. Did you maybe forget to add a "use" statement for this annotation?`. As you see it tryes find annotation with name "@todo:". Don't know, maybe rtrim($name, ':') would enough. |
[DCOM-191] Wrong inflection for "identity" Created: 07/May/13 Updated: 07/May/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Tom Vogt | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
OS X and Linux, PHP 5.4.x |
||
| Description |
|
console doctrine:generate:entities For an association named "identities", the code generator creates the two methods |
[DCOM-180] Entity with field $key passes orm:validate but db create will fail Created: 03/Mar/13 Updated: 03/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine Common |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Trivial |
| Reporter: | exoon | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
apache2 php mysql |
||
| Description |
|
There should be a warning if you name a field $key. |