[DDC-3849] [GH-1476] Enhancement: Enable caching of dependencies between builds Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: build-speed, cache, ci, composer, travis


 Description   

This issue is created automatically through a Github pull request on behalf of localheinz:

Url: https://github.com/doctrine/doctrine2/pull/1476

Message:

This PR

  • [x] enables caching of dependencies as installed with Composer between builds


 Comments   
Comment by Doctrine Bot [ 24/Jul/15 ]

A related Github Pull-Request [GH-1476] was closed:
https://github.com/doctrine/doctrine2/pull/1476





[DDC-3704] [GH-1390] Document the ChainCache class Created: 20/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.6.0
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, chain-cache, documentation


 Description   

This issue is created automatically through a Github pull request on behalf of deviantintegral:

Url: https://github.com/doctrine/doctrine2/pull/1390

Message:

I was thisclose to writing a ChainCache class myself, and only avoided it by actually looking in the source. There's no mention of ChainCache on Google, probably because there's no docs for it. ChainCache is a bit different from other drivers in that it's something implementers will want to use in their own code in place of an ArrayCache or static array. However, I also added a link to the cache drivers given there's quite a few that aren't mentioned in the docs.






[DDC-3689] [GH-1382] Patch second level cache association hydration Created: 14/Apr/15  Updated: 15/Apr/15  Resolved: 14/Apr/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Second Level Cache
Affects Version/s: 2.5
Fix Version/s: 2.5.1, 2.6.0
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: cache, orm

Issue Links:
Reference
is referenced by DDC-3687 Entities part of a hierarchy seem not... Open

 Description   

This issue is created automatically through a Github pull request on behalf of holtkamp:

Url: https://github.com/doctrine/doctrine2/pull/1382

Message:

Fixed incorrect use of keys in DefaultRegion::getMultiple() and simplified overall mechanism



 Comments   
Comment by Doctrine Bot [ 14/Apr/15 ]

A related Github Pull-Request [GH-1382] was labeled:
https://github.com/doctrine/doctrine2/pull/1382

Comment by Doctrine Bot [ 14/Apr/15 ]

A related Github Pull-Request [GH-1382] was assigned:
https://github.com/doctrine/doctrine2/pull/1382

Comment by Doctrine Bot [ 14/Apr/15 ]

A related Github Pull-Request [GH-1382] was merged:
https://github.com/doctrine/doctrine2/pull/1382

Comment by Guilherme Blanco [ 14/Apr/15 ]

Master: https://github.com/doctrine/doctrine2/commit/5f1861835535c5bd90cf69f5a24f65488975a073
2.5: https://github.com/doctrine/doctrine2/commit/3e6c6af8456a1b2a1ecd5c868be6f792bc857828

Comment by Doctrine Bot [ 15/Apr/15 ]

A related Github Pull-Request [GH-1382] was unassigned:
https://github.com/doctrine/doctrine2/pull/1382

Comment by Doctrine Bot [ 15/Apr/15 ]

A related Github Pull-Request [GH-1382] was assigned:
https://github.com/doctrine/doctrine2/pull/1382





[DDC-3683] [GH-1380] Fix issue with second-level-cache tests and versioned entities Created: 10/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Second Level Cache
Affects Version/s: Git Master, 2.5
Fix Version/s: 2.5.1, 2.6.0
Security Level: All

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, testing, version

Issue Links:
Dependency
is required for DDC-3681 [GH-1378] Feature to force-increment ... Closed

 Description   

This issue is created automatically through a Github pull request on behalf of DHager:

Url: https://github.com/doctrine/doctrine2/pull/1380

Message:

I'm not sure why this bug doesn't show normally `master`, but I ran across it with build [3930.1](https://travis-ci.org/doctrine/doctrine2/jobs/57975906), where it complained since `$targetPersister` was not an instance of `CachedPersister`.

The immediate fix seems straightforward, because `DefaultCollectionHydrator` doesn't even accept the second argument.

@FabioBatSilva : Please let me know if you see some better resolution to this, or if it indicates some edge-case in the second-level-cache logic that requires a new test.



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

A related Github Pull-Request [GH-1380] was closed:
https://github.com/doctrine/doctrine2/pull/1380





[DDC-3651] [GH-1358] Update docs for clear-cache commands Created: 01/Apr/15  Updated: 02/Apr/15  Resolved: 02/Apr/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, Tools
Affects Version/s: Git Master
Fix Version/s: 2.5
Security Level: All

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, clear-cache, cli, documentation


 Description   

This issue is created automatically through a Github pull request on behalf of zerocrates:

Url: https://github.com/doctrine/doctrine2/pull/1358

Message:

The current docs appear to refer to an older version of the clear-cache commands.

The "clear all caches" command doesn't appear to exist anymore, and the three more specific options for clearing the metadata, query, and result caches are now separate tasks instead of options on one.



 Comments   
Comment by Doctrine Bot [ 02/Apr/15 ]

A related Github Pull-Request [GH-1358] was labeled:
https://github.com/doctrine/doctrine2/pull/1358

Comment by Doctrine Bot [ 02/Apr/15 ]

A related Github Pull-Request [GH-1358] was assigned:
https://github.com/doctrine/doctrine2/pull/1358

Comment by Doctrine Bot [ 02/Apr/15 ]

A related Github Pull-Request [GH-1358] was merged:
https://github.com/doctrine/doctrine2/pull/1358





[DDC-3631] [GH-1344] Fix tests for SLC console commands failing due to console output decoration Created: 20/Mar/15  Updated: 22/Mar/15  Resolved: 22/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Second Level Cache, Tools
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: cache, console, second-level-cache, tools


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/doctrine2/pull/1344

Message:

The tests for the SLC console commands were failing on my box because the console output was being decorated with ANSI color codes, while the test assertions were using undecorated strings.

This PR turns off output decoration when these console commands are executed in the tests.



 Comments   
Comment by Doctrine Bot [ 20/Mar/15 ]

A related Github Pull-Request [GH-1344] was merged:
https://github.com/doctrine/doctrine2/pull/1344

Comment by Doctrine Bot [ 22/Mar/15 ]

A related Github Pull-Request [GH-1344] was labeled:
https://github.com/doctrine/doctrine2/pull/1344

Comment by Doctrine Bot [ 22/Mar/15 ]

A related Github Pull-Request [GH-1344] was assigned:
https://github.com/doctrine/doctrine2/pull/1344





[DDC-3625] [GH-1339] [DDC-2224] Honor convertToDatabaseValueSQL() in DQL query parameters Created: 18/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, dql, parameter

Issue Links:
Dependency
is required for DDC-2224 convertToDatabaseValueSQL() is not ho... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/doctrine2/pull/1339

Message:

This is a follow-up to the abandoned #574 by @mnapoli, that fixes DDC-2224(http://www.doctrine-project.org/jira/browse/DDC-2224).

At the time, @beberlei closed the PR for the following reason, deemed unfixable:

> Passing a type into the parameters is not recognized during caching, that means, using a DQL cache, the same DQL statement with (different parameter types) will lead to the same SQL being generated, depending on if the first or the second set parameter query is executed first.

This PR re-integrates the original fix, and offers a solution to the above issue: take the parameter types into account when checking the local `ParserResult` and the query cache.

In addition to the test for the DDC-2224 issue, I added a test to ensure that changing a parameter type invalidates the cache.



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

A related Github Pull-Request [GH-1339] was unlabeled:
https://github.com/doctrine/doctrine2/pull/1339

Comment by Doctrine Bot [ 25/Mar/15 ]

A related Github Pull-Request [GH-1339] was assigned:
https://github.com/doctrine/doctrine2/pull/1339

Comment by Doctrine Bot [ 25/Mar/15 ]

A related Github Pull-Request [GH-1339] was merged:
https://github.com/doctrine/doctrine2/pull/1339





[DDC-3566] [GH-1302] Store column values of not cache-able associations Created: 11/Feb/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM, Second Level Cache
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: association, cache, non-cacheable, partial

Issue Links:
Dependency
is required for DDC-3564 [GH-1301] Add failing test with ToOne... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/1302

Message:

Fixes #1301



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

A related Github Pull-Request [GH-1302] was assigned:
https://github.com/doctrine/doctrine2/pull/1302

Comment by Doctrine Bot [ 17/Mar/15 ]

A related Github Pull-Request [GH-1302] was unlabeled:
https://github.com/doctrine/doctrine2/pull/1302





[DDC-3564] [GH-1301] Add failing test with ToOne SL2 association Created: 11/Feb/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM, Second Level Cache
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: association, cache, non-cacheable, partial

Issue Links:
Dependency
depends on DDC-3566 [GH-1302] Store column values of not ... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of bakura10:

Url: https://github.com/doctrine/doctrine2/pull/1301

Message:

Hi,

This failing test is based on @FabioBatSilva tests here (https://github.com/FabioBatSilva/doctrine2/blob/4f7e71963f5197235fce9f87a56b02bbbba46026/tests/Doctrine/Tests/ORM/Functional/SecondLevelCacheOneToOneTest.php).

I've changed the test so that on Token association, there is no @Cache annotation.

The default behaviour would be to Doctrine set a proxy on non-cached association. Instead, it basically creates a "partial" object where any associations without the @Cache is set to null. I'm pretty sure it works the same ManyToOne association too.



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

A related Github Pull-Request [GH-1301] was labeled:
https://github.com/doctrine/doctrine2/pull/1301

Comment by Doctrine Bot [ 16/Feb/15 ]

A related Github Pull-Request [GH-1301] was assigned:
https://github.com/doctrine/doctrine2/pull/1301

Comment by Marco Pivetta [ 17/Mar/15 ]

Handled in DDC-3566





[DDC-3506] [GH-1259] Hotfix: Cache region should not mutate injected cache instance settings Created: 15/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Second Level Cache
Affects Version/s: Git Master
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, cache-namespace, cache-region, factory


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/1259

Message:

This is strictly related to https://github.com/doctrine/cache/pull/48#discussion_r19059174 as well



 Comments   
Comment by Doctrine Bot [ 15/Jan/15 ]

A related Github Pull-Request [GH-1259] was assigned:
https://github.com/doctrine/doctrine2/pull/1259

Comment by Doctrine Bot [ 15/Jan/15 ]

A related Github Pull-Request [GH-1259] was merged:
https://github.com/doctrine/doctrine2/pull/1259





[DDC-3457] [GH-1227] Ensure query cache is not ArrayCache in production Created: 19/Dec/14  Updated: 09/Jan/15  Resolved: 09/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, cli, command, production-settings

Issue Links:
Reference
relates to DDC-3379 [GH-1177] Ensure metadata cache is no... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of c960657:

Url: https://github.com/doctrine/doctrine2/pull/1227

Message:

This PR applies the same check for the query cache that was done for the metadata cache in #1177 (as suggested by @stof).



 Comments   
Comment by Doctrine Bot [ 09/Jan/15 ]

A related Github Pull-Request [GH-1227] was assigned:
https://github.com/doctrine/doctrine2/pull/1227

Comment by Doctrine Bot [ 09/Jan/15 ]

A related Github Pull-Request [GH-1227] was merged:
https://github.com/doctrine/doctrine2/pull/1227





[DDC-3400] Wrong result using php-cli Created: 19/Nov/14  Updated: 20/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Damir Abdijevic Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: cache, cli, dql, environment, orm
Environment:

Windows 7, Debian GNU/Linux 7 PHP 5.5.15



 Description   

Same query produces different results. With apache module everything works like expected. With php-cli the join condition to i18n table is ignored and calling getCountries() returns all and not only that entity that is matched by join condition.

        $qb = $this->_em->createQueryBuilder()
                        ->select('t', 'i18n')
                        ->from($this->_entityName, 't')
                        ->innerJoin('t.countries', 'i18n')
                        ->where('i18n.locale = :localeId')
                        ->setParameter('localeId', $localeId);

Country Entity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;
use Doctrine\Common\Collections\ArrayCollection;

/**
 * Country entity
 *
 * @ORM\Entity(repositoryClass="MyApp\Model\Repository\Country")
 * @ORM\Table(name="country")
 *
 */
class Country
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var string
     * @ORM\Column(type="string", name="name", length=32, unique=true)
     */
    protected $name;

    /**
     * @var int
     * @ORM\Column(type="integer", name="sort", unique=true)
     */
    protected $sort;

    /**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="ProductDescription\Model\Entity\CountryI18n", mappedBy="country", cascade={"all"})
     */
    protected $countries;


    /**
     * Constructor
     *
     * @return Country
     */
    public function __construct()
    {
        $this->countries = new ArrayCollection();
    }

    /**
     * Getter for $this->id
     *
     * @return int
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Setter for $this->id
     *
     * @param int $id entity id
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->sort
     *
     * @return int
     */
    public function getSort()
    {
        return $this->sort;
    }

    /**
     * Setter for $this->sort
     *
     * @param int $sort sort order
     *
     * @return void
     */
    public function setSort($sort)
    {
        $this->sort = (int) $sort;
    }

    /**
     * Getter for $this->name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * Setter for $this->name
     *
     * @param string $name language name in german
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

   /**
    * Get collection from i18n table
    *
    * @return ArrayCollection
    */
    public function getCountries()
    {
        return $this->countries;
    }

    /**
     * Proxy method. So we have working with all entities same method
     * to getting i18n data.
     *
     * @return ArrayCollection
     */
    public function getI18n()
    {
        return $this->getCountries();
    }

CountryI18nEntity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * CountryI18n entity
 *
 * @ORM\Entity
 * @ORM\Table(name="country_i18n", uniqueConstraints={@ORM\UniqueConstraint(name="idx_UNIQUE_country_id_locale_id", columns={"country_id", "locale_id"})})
 */
class CountryI18n
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Country", inversedBy="countries")
     * @ORM\JoinColumn(name="country_id", referencedColumnName="id")
     */
    protected $country;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Language", inversedBy="countries")
     * @ORM\JoinColumn(name="locale_id", referencedColumnName="id")
     */
    protected $locale;

    /**
     * @var string
     * @ORM\Column(type="string", name="name", length=255)
     */
    protected $name;


    /**
     * Getter for $this->id
     *
     * @return int
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Setter for $this->id
     *
     * @param int $id id of row primary key
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->country
     *
     * @return Country
     */
    public function getCountry()
    {
        return $this->country;
    }

    /**
     * Setter for $this->country
     *
     * @param Country $country country entity to set
     *
     * @return void
     */
    public function setCountry(Country $country)
    {
        $this->country = $country;
    }

    /**
     * Getter for $this->locale
     *
     * @return Language
     */
    public function getLocale()
    {
        return $this->locale;
    }

    /**
     * Setter for $this->locale
     *
     * @param Language $locale language entity to set as locale
     *
     * @return void
     */
    public function setLocale(Language $locale)
    {
        $this->locale = $locale;
    }

    /**
     * Getter for $this->name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * Setter for $this->name
     *
     * @param string $name translation name
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

}


 Comments   
Comment by Marco Pivetta [ 19/Nov/14 ]

Looks like a caching issue. The amount of information provided is insufficient as it is. I'd suggest verifying if the generated SQL is the same, and checking that all caches were cleared both in CLI and in WEB sapis.

Comment by Damir Abdijevic [ 20/Nov/14 ]

O.k. here some further information.

No caching like Xcache or APC is enabled. PHP 5.5 integrated opcache ist not enabled. All Doctrine caches are set to Array. The sql queries are in both cases exactly the same:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, c1_.country_id AS country_id5, c1_.locale_id AS locale_id6 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id WHERE c1_.locale_id = ?

/* locale_id = 2 */

The sql result is correct

Running the console script a ZF2 Initializer runs before that performs this query builder query:

QueryBuilder

$qb = $this->_em->createQueryBuilder()
                            ->select('t', 'i18n', 'l')
                            ->from($this->_entityName, 't')
                            ->innerJoin('t.countries', 'i18n')
                            ->innerJoin('i18n.locale', 'l');

That results in following SQL:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, l2_.id AS id5, l2_.name AS name6, l2_.full_name AS full_name7, l2_.locale AS locale8, c1_.country_id AS country_id9, c1_.locale_id AS locale_id10, l2_.country_id AS country_id11 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id INNER JOIN language l2_ ON c1_.locale_id = l2_.id
Comment by Marco Pivetta [ 20/Nov/14 ]

What happens if you run those SQL statements via CLI (dbal:run-sql) or WEB? Same results?

Comment by Damir Abdijevic [ 20/Nov/14 ]

The sql result is correct. Can I attach it to the ticket? I have exported it to csv.

Comment by Marco Pivetta [ 20/Nov/14 ]

If the same results are produced on CLI and WEB APIs then I suggest trying to insulate the issue in a functional test to be run in both context. You probably have a different ORM bootstrap for CLI and WEB.

Attaching a CSV for same results makes no real difference here.

Comment by Damir Abdijevic [ 20/Nov/14 ]

No, I didn't want to attach two times the same result. Wanted to attach it one time to show that those entitites that are wrong in the result doesn't appear in the sql result at all. I don't have different bootstraps. After a few short tests I think it is an error in th ArrayCache mechanism. The difference was that using Apache one initializer was not called. Calling this initializer in both cases leads now to wrong results in CLI and WEB API.

When the second query is not executed everything is fine. But when the second longer query runs and selects all i18n entities and after it the first query runs then the issue appears.





[DDC-3379] [GH-1177] Ensure metadata cache is not ArrayCache in production Created: 08/Nov/14  Updated: 19/Dec/14  Resolved: 11/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: 2.4.6
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: array-cache, cache, configuration, production-settings

Issue Links:
Reference
is referenced by DDC-3457 [GH-1227] Ensure query cache is not A... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of c960657:

Url: https://github.com/doctrine/doctrine2/pull/1177

Message:

This PR adds a new check to Configuration::ensureProductionSettings(). It ensures that the metadata cache does not use ArrayCache in production.

The ArrayCache forgets everything at the end of each request, while the other bundled cache engines (Memcache, MongoDB, FileCache etc.) may keep entries for much longer. The metadata only changes when the source files are changed, so in production the metadata cache only needs to be cleared when new files are deployed, just like the generation of proxy classes.

It is possible to specify/modify metadata dynamically at runtime e.g. using the loadClassMetadata event so that the metadata changes without any changes to the source files, but I assume this is not a supported use-case (at least not without clearing the metadata cache manually). Agree?

The ArrayCache is the default cache engine added by e.g. Doctrine Bundle (for Symfony) and Doctrine ORM Service Provider (for Silex), so most developers are probably not aware of it. However, accessing the metadata at run-time has a significant performance impact (for some anecdotal evidence, see https://github.com/doctrine/common/pull/319#issuecomment-60945429), so a warning in ensureProductionSettings() is relevant.

The PR also fixes the units for ensureProductionSettings() that were previously not being run due to a missing "test" prefix on the ConfigurationTest::ensureProductionSettings method name.



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

A related Github Pull-Request [GH-1177] was assigned:
https://github.com/doctrine/doctrine2/pull/1177





[DDC-3174] Query Cache not correct working when using SQLFilter Created: 17/Jun/14  Updated: 17/Jul/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benno Eggnauer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: cache, sqlfilter


 Description   

We have an SQLFilter to filter on entities with a specific Trait implemented. The filter is very easy:

$res = $targetTableAlias . '.agency_id = ' . $this->getCurrentAgencyId();

On our system we have the query cache enabled, this works as long the "AgencyId" doesn't change. When the ID changes, the query cache seems to return the wrong (old cache) query.



 Comments   
Comment by Marco Pivetta [ 17/Jun/14 ]

I'm not sure if this case should be contemplated by the ORM. Filters are low-level and supposed to be stateless (services).

Comment by Benno Eggnauer [ 17/Jun/14 ]

OK, we can disable the query cache for this case. But then should at least the documentation be updated, which explicitly mentions to use filter for locales, which are also not stateless: http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html#example-filter-class

Also in the query cache chapter: http://doctrine-orm.readthedocs.org/en/latest/reference/caching.html#query-cache

It is highly recommended that in a production environment you cache the transformation of a DQL query to its SQL counterpart. It doesn’t make sense to do this parsing multiple times as it doesn’t change unless you alter the DQL query.

Comment by Marco Pivetta [ 17/Jun/14 ]

Benno Eggnauer can you eventually provide a pull request?

Comment by James Blizzard [ 01/Dec/14 ]

I would just like to say that we're having exactly the same issue. I'd love some method (official or not) of having filters being taken into account in this situation.

Comment by Guglielmo Carandente [ 16/Jan/15 ]

I have the same problem when is generated QueryCacheId It consider only the name of active filters and not the value of the filter
This is the code at line 646 of class \Doctrine\ORM\Query
protected function _getQueryCacheId()

{ ksort($this->_hints); return md5( $this->getDql() . var_export($this->_hints, true) . ($this->_em->hasFilters() ? $this->_em->getFilters()->getHash() : '') . '&firstResult=' . $this->_firstResult . '&maxResult=' . $this->_maxResults . '&hydrationMode='.$this->_hydrationMode.'DOCTRINE_QUERY_CACHE_SALT' ); }
Comment by Pele Odiase [ 08/Jul/15 ]

I also have the same issue, there are circumstances where filters are dynamic and not stateless particularly when dealing with multi-site / multi-lingual platforms. Is there an appetite for the ORM to take this into consideration.

Comment by Bram Gerritsen [ 17/Jul/15 ]

I have the same issue. We are using SQL filters a lot to filter entities by website and locale. It would be nice if the filter values can be taken into account as well. For now I disabled the query cache in the concerning repositories.





[DDC-3078] Doctrine\ORM\Cache::__construct is in an interface Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: Git Master
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Blocker
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, config, second-level-cache

Issue Links:
Dependency
depends on DDC-3080 [GH-1008] DDC-3078 SLC Cache interfac... Resolved

 Description   

CTOR in the interface is a huge problem. This absolutely needs to be fixed before 2.5 is released, or we will have trouble in future.

I'm writing a PoC patch right now.



 Comments   
Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-2982] [GH-954] Multi Get support for Second Level Cache Created: 14/Feb/14  Updated: 17/Jan/15  Resolved: 17/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Second Level Cache
Affects Version/s: Git Master
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, multi-get, performance, second-level-cache

Issue Links:
Reference
relates to DDC-2981 Multi get for second level cache (Doc... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/954

Message:

Hi!
As discussed [here](http://www.doctrine-project.org/jira/browse/DDC-2981) i have implemented some kind of multi-get for second level cache implementation.

I have also created a PR to doctrine/cache component (see https://github.com/doctrine/cache/pull/29) that enables this feature at driver cache level.



 Comments   
Comment by Doctrine Bot [ 15/Jan/15 ]

A related Github Pull-Request [GH-954] was assigned:
https://github.com/doctrine/doctrine2/pull/954

Comment by Doctrine Bot [ 17/Jan/15 ]

A related Github Pull-Request [GH-954] was closed:
https://github.com/doctrine/doctrine2/pull/954





[DDC-2981] Multi get for second level cache (Doctrine Cache related) Created: 13/Feb/14  Updated: 17/Jan/15  Resolved: 17/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM, Second Level Cache
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: Asmir Mustafic Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, multi-get, performance, second-level-cache

Issue Links:
Reference
is referenced by DDC-2982 [GH-954] Multi Get support for Second... Resolved

 Description   

Hi every body!

I'm developing an application that is highly based on doctrine second-level cache feature.
Using memcache or redis as cache back-end, doctrine have to query thousand times for the cached values (especially on one-to-many and many-to-many associations).
This introduces a lot of latency (and network traffic)...

I'm thinking to add to Doctrine\Common\Cache\Cache interface a method fetchMulti(array $keys) that fetches multiple items in one call. In this way doctrine orm can ask for many items with just one call (for example, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultCollectionHydrator.php#L84 this feature can be very useful).

I have made some real-world tests and it can reduce highly the number of total queries (my app runs 190 cache requests instead of 900 cache requests)

Many vendors (memcache, redis, apc ecc) already offer this functionality, but with doctrine-cache we can't use it...

I'm going to implement this feature. Can it be accepted as a pull request?

It may be BC breaking:

  • it can be implemented adding a method inside Doctrine\Common\Cache\Cache interface (more BC breaking but more clean and elegant)
  • it can be implemented adding an interface Doctrine\Common\Cache\MultiCache and later CacheProvider can implement it (less BC breaking)


 Comments   
Comment by Marco Pivetta [ 13/Feb/14 ]

Adding a method to Doctrine\Common\Cache\Cache is not viable because of BC - a new interface would be ok

Comment by Asmir Mustafic [ 13/Feb/14 ]

ok, i agree with you.
But this forces me to check always here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/Region/DefaultRegion.php#L95 if $this->cache is instance of MultiCache

Comment by Marco Pivetta [ 13/Feb/14 ]

Asmir Mustafic or you build a MultiCacheRegion

Comment by Asmir Mustafic [ 13/Feb/14 ]

It can be a good approach. I will try it.
I'm thinking to provide a default implementation of fetchMulti directly inside CacheProvider that internally loops over each key and call CacheProvider::fetch($id) to fetch its value.
Later i will overwrite this behavior inside vendor specific driver (ApcCache, RedisCache...)

Comment by Marco Pivetta [ 17/Jan/15 ]

Solved in DDC-2982





[DDC-2570] Doctrine CLI Tools - Clear All Cache Created: 24/Jul/13  Updated: 17/Jan/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: 2.3.4
Fix Version/s: 2.x

Type: Improvement Priority: Minor
Reporter: Frederick Marcoux Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: Cli, cache, orm


 Description   

It would be nice to be able to clear all cache one shot instead of clearing them one after one...

Like this:

root$ ./doctrine orm:clear-cache:all

Instead of:

root$ ./doctrine orm:clear-cache:metadata
root$ ./doctrine orm:clear-cache:result
root$ ./doctrine orm:clear-cache:query






[DDC-2164] Extend the cache support to eAccelerator Created: 23/Nov/12  Updated: 26/Nov/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 3.0
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Enea Bette Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cache, drivers


 Description   

It would be nice if the Doctrine caching drivers would support the eAccelerator library.



 Comments   
Comment by Marco Pivetta [ 23/Nov/12 ]

Enea Bette eAccelerator is known for being stripping comments from cached source (making it impossible to use annotations)... Do you happen to know if this is fixed? Supporting it as cache driver is fine btw, I just wonder how many users will start thinking of using eAccelerator and then will be facing this huge limitation.

Comment by Enea Bette [ 26/Nov/12 ]

I know that eAccelerator has this issue. It would be nice if we could utilize it with XML, YML and PHP based mapping though.
Do you know if the same problem would appear with these kinds of mapping strategies?

To give response to your question (eAccelerator and annotations incompatibility), there is a pull request on github, https://github.com/eaccelerator/eaccelerator/issues/19 .

It seems that in the future these could be resolved, and at that time it would be very nice to have that supported with doctrine (symfony2 already has support for this library).

"I just wonder how many users will start thinking of using eAccelerator and then will be facing this huge limitation". Sometimes users just does not have a choice. Imagine the case when you have a hosted site that requires caching functionalities and the only available cache library is eAccelerator (as just in my case). You would be fried as a chicken hehe





[DDC-2155] problem with DQL and cache Created: 18/Nov/12  Updated: 25/Nov/12  Resolved: 25/Nov/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: gabriel sancho Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: cache, dql
Environment:

linux , php 5.4.8, mysql 5.5.28



 Description   

I have a problem when I get database records through a query DQL
and then they are changed by another application
If I repeat the query, Doctrine always return the first value, not the current value of the base

<?php

// bootstrap

$cache = new \Doctrine\Common\Cache\ArrayCache();
$config = new Doctrine\ORM\Configuration();
$config->setQueryCacheImpl($cache);
$conn = array(
				'dbname' => $database_name,
				'user' => $cnx_user,
				'password' => $cnx_pass,
				'host' => $cnx_host,
				'driver' => $cnx_type,
				'charset' => 'utf8',
				'driverOptions' => array( 1002 => "SET NAMES 'utf8'" )
				);

			$em = Doctrine\ORM\EntityManager::create($conn, $config);




while(true){
   $dql = "SELECT s from Register s WHERE s.id = 1";
   $query = $em->createQuery($dql);
// the next line is optional, produces same result
   $query->useResultCache(false);
   $res = $query->getResult();
   $orm = reset($res);
   	
   echo " regiter id :".$orm->getId()."  field "$orm->getText()."\n";

}

I run this code in a terminal, and then edit the registry (field text), but the terminal still shows the same result



 Comments   
Comment by Benjamin Eberlei [ 25/Nov/12 ]

Doctrine uses an IdentityMap pattern which leads to this issue.

You need to call "EntityManager#clear()" to clean the in memory cache of Doctrine and fetch records from the database again. or call "EntityManager#refresh($entity)"





Generated at Sat Aug 01 20:21:54 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.