We are using Redis for as the caching driver for Doctrine in Symfony4.4. We are using the Doctrine's metadata_cache_driver, query_cache_driver, result_cache_driver which saves the cache data into Redis.
But we now face an issue with the keys created by the result_cache_driver of doctrine. The key contains [ , ] characters which is making it difficult to identify and delete the cache key, especially when deleting the cache via redis-cli.
For eg some of the cache keys are:
doctrine.result:[myapp_user_language_14922][1]
doctrine.result:[myapp_userdetails_11853][1]
Is this the default behavior of the Symfony_Doctrine or any issue with configuration issue?
Is there any way we can change the structure of the KEYS to doctrine.result:myapp_user_language_14922 ?
We are using
Symfony 4.4.30
doctrine/cache 1.12.1
doctrine/dbal 2.13.3
doctrine/doctrine-bundle 1.12.13
doctrine/doctrine-cache-bundle 1.4.0
doctrine/orm 2.7.5
Related
Environnement:
php 8.1
symfony 5.4
doctrine/dbal 3.3
doctrine/doctrine-bundle 2.7
doctrine/migrations 3.5.1
postgresql 14.4
My problem is the following;
We have a database containing several schema to separate the data useful to the system and those published directly to users.
We use of course the classic entity declaration with Symfony & Doctrine:
/**
* #ORM\Table(name="stats", schema="system")
* #ORM\Entity(repositoryClass="App\Repository\System\StatsRepository")
*/
class Stats
The problem is that when we delete a relation between the public schema and the system schema, the migration generated by the command bin/console doctrine:schema:update has an error when deleting the index.
Here is the migration generated:
public function up(Schema $schema): void
{
// this up() migration is auto-generated, please modify it to your needs
$this->addSql('DROP INDEX idx_2225600edc6d4b4b');
$this->addSql('ALTER TABLE system.stats DROP article_id');
}
The problem being that in deleting the index, the line forgets to specify that the index comes from the system schema.
We need:
$this->addSql('DROP INDEX system.idx_2225600edc6d4b4b');
We want to keep the bin/console doctrine:schema:update operation for updating the database, but this problem now forces us to use the migration system to change the drop index.
I know that the obvious solution would be to use the migration system (bin/console make:migration) but this implies some changes in the IC. That's why I'm wondering; have you ever had this problem? If yes, how did you solve the problem?
After creating an Entity and Repository from an existing pre-doctrine database, I am unable to make an initial migration. It gave me this error [ERROR] The version "latest" couldn't be reached, there are no registered migrations. Any idea how to do an initial migration without starting fresh? And for some reason, the migration folder exists outside the src folder, why is it so? In a previous project, the migration folder exists inside the src folder.
Any insight would be appreciated. Thank you for reading.
EDIT: doctrine_migrations.yaml:
doctrine_migrations:
migrations_paths:
# namespace is arbitrary but should be different from App\Migrations
# as migrations classes should NOT be autoloaded
'DoctrineMigrations': '%kernel.project_dir%/migrations'
The commands I used to generate the Entity and its Repository is as follows:
php bin/console doctrine:mapping:import "App\Entity" annotation --path=src/Entity
modified the #ORM\Entity => #ORM\Entity(repositoryClass="App\Repository\UserRepository") in the entity .php
php bin/console make:entity --regenerate
Then when I run bin/console doctrine:migrations:migrate, the error pops up.
Work for me
doctrine_migrations:
migrations_paths:
'App\Migrations': '%kernel.project_dir%/src/Migrations'
and use for migration classes
namespace App\Migrations;
THis is my migrations config.You can test it :
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/Migrations'
# namespace is arbitrary but should be different from App\Migrations
# as migrations classes should NOT be autoloaded
namespace: DoctrineMigrations
For migration commande i use : php bin/console d:m:diff and after this you can use the migration number with this commande :
php bin/console d:m:e --up the_migration_number
I tried most of the methods but it seems that it is possible to generate the migration. However, changes to the entity will not be detected by doctrine.
For example, if I change the field of name to username, php bin/console doctrine:migration:diff does not detect the changes.
What I found worked was exporting the database as .sql, creating the entity the normal way, and manually typing in the fields. Delete the generated table in phpmyadmin, and importing the data back in. Only then would it be working as I want it to be.
On symfony 4.3 (doctrine 2.10)
all migrations contain the same lines, even without entity changes...
example:
ALTER TABLE file_master CHANGE file_name file_name VARCHAR(255) DEFAULT NULL')
do you have the same issue?
Tkx.
Cédric
I had the same issue with mariadb database. I changed database version in doctrine.yaml file and it worked for me:
doctrine:
dbal:
server_version: 'mariadb-10.4.7'
I took server version from phpMyAdmin. Before this value was '5.7'
This might be linked to this particular issue : https://github.com/doctrine/dbal/issues/3006 in Doctrine.
One workaround that seem to work is to make sure that if any of your entity's field has an option parameter containing default, it should be equal to 1 like this, and not be just a key (options={"default"}):
#ORM\Column(name="field", type="integer", length=8, options={"default": 1 })
See https://github.com/doctrine/orm/issues/6845
Hope that helps
If you are using MariaDB here is an article about that issue: https://marenkay.com/post/symfony-doctrine-mariadb/
I've solved it by simply removing server_version from the doctrine config completely. Otherwise you have to specify the mariadb version, for example "mariadb-10.3.18" instead of the mysql version.
I am using FOSUserBundle in my Symfony 2.7 project. In the composer.json file the requirement is defined as "friendsofsymfony/user-bundle" : "~2.0#dev". Currently version/commit 45d6f40 (11/03/2015) is installed.
After using composer update the latest version 7abb0ff was installed. After this, I get the following exception when trying to create new users:
The field 'usernameCanonical' is not mapped by Doctrine, so it cannot be validated for uniqueness
Searching for solution for this problem brought up older issues dealing with the same exception (here and here). However I was not able to solve the problem with the solution discussed in these issues.
Issue 1565 proposes to use FOS\UserBundle\Entity\User as BaseUser; instead of FOS\UserBundle\Model\User as BaseUser;. But this solution seems not to be valid for version 2.x. The 2.x documentation says that you should extend from FOS\UserBundle\Model\User, which makes sense since there are no FOS\UserBundle\Entity\... classes anymore.
My User class looks like this:
namespace AppBundle\Entity;
use FOS\UserBundle\Model\User as BaseUser;
use Doctrine\ORM\Mapping as ORM;
/**
* This class represents the User entity and extends the FOSBundle base user
* Entity class to be able to use FOSUserBundle to manage the application users.
*
* #ORM\Entity(repositoryClass="AppBundle\Entity\UserRepository")
* #ORM\Table(name="app_user") *
* #ORM\HasLifecycleCallbacks()
*/
class User extends BaseUser {
...
}
In Issue 1638 the solution was to use auto_mapping in the Doctrine configuration. I already did this.
So neither of the existing solutions worked for my. Additional all existing issues to this problem are quite old.
Of course I could simply downgrade back to version/commit 45d6f40. However I would prefer to solve the problem instead of ignoring it :-)
Any other idea how I can solve this?
PS: This is my composer show -i output:
doctrine/annotations v1.2.7 Docblock Annotations Parser
doctrine/cache v1.6.0 Caching library offering an object-oriented API for many cache backends
doctrine/collections v1.3.0 Collections Abstraction library
doctrine/common v2.6.1 Common Library for Doctrine projects
doctrine/dbal v2.4.5 Database Abstraction Layer
doctrine/doctrine-bundle v1.2.0 Symfony DoctrineBundle
doctrine/inflector v1.0.1 Common String Manipulations with regard to casing and singular/plural rules.
doctrine/instantiator 1.0.5 A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer v1.0.1 Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
doctrine/orm v2.4.8 Object-Relational-Mapper for PHP
friendsofsymfony/http-cache 1.4.0 Tools to manage cache invalidation
friendsofsymfony/http-cache-bundle 1.3.4 Set path based HTTP cache headers and send invalidation requests to your HTTP cache
friendsofsymfony/rest-bundle 1.4.2 This Bundle provides various tools to rapidly develop RESTful API's with Symfony2
friendsofsymfony/user-bundle dev-master 7abb0ff Symfony FOSUserBundle
gremo/buzz-bundle v1.1.0 Symfony Bundle for using the lightweight Buzz HTTP client.
guzzle/guzzle v3.9.3 PHP HTTP client. This library is deprecated in favor of https://packagist.org/packages/guzzlehttp/guzzle
jdorn/sql-formatter v1.2.17 a PHP SQL highlighting library
jms/metadata 1.5.1 Class/method/property metadata management in PHP
jms/parser-lib 1.0.0 A library for easily creating recursive-descent parsers.
jms/serializer 1.3.1 Library for (de-)serializing data of any complexity; supports XML, JSON, and YAML.
jms/serializer-bundle 1.1.0 Allows you to easily serialize, and deserialize data of any complexity
kriswallsmith/assetic v1.3.2 Asset Management for PHP
kriswallsmith/buzz v0.15 Lightweight HTTP client
leafo/scssphp v0.6.6 scssphp is a compiler for SCSS written in PHP.
moontoast/math 1.1.0 A mathematics library, providing functionality for large numbers
paragonie/random_compat v2.0.2 PHP 5.x polyfill for random_bytes() and random_int() from PHP 7
phpcollection/phpcollection 0.5.0 General-Purpose Collection Library for PHP
phpoption/phpoption 1.5.0 Option Type for PHP
psr/log 1.0.0 Common interface for logging libraries
sensio/distribution-bundle v2.3.22 The base bundle for the Symfony Distributions
sensio/framework-extra-bundle v2.3.4 This bundle provides a way to configure your controllers with annotations
sensio/generator-bundle v2.3.5 This bundle generates code for you
swiftmailer/swiftmailer v5.4.3 Swiftmailer, free feature-rich PHP mailer
symfony/assetic-bundle v2.7.1 Integrates Assetic into Symfony2
symfony/monolog-bundle v2.8.2 Symfony MonologBundle
symfony/swiftmailer-bundle v2.3.11 Symfony SwiftmailerBundle
symfony/symfony v2.7.7 The Symfony PHP framework
tfox/mpdf-port-bundle 1.3.1 A wrapper for mPDF class which allows to use mPDF in Symfony2 projects
twig/extensions v1.0.1 Common additional features for Twig that do not directly belong in core
twig/twig v1.25.0 Twig, the flexible, fast, and secure template language for PHP
willdurand/jsonp-callback-validator v1.1.0 JSONP callback validator.
willdurand/negotiation 1.5.0 Content Negotiation tools for PHP provided as a standalone library.
Maybe this solve someone problems when you get the error
The field 'usernameCanonical' is not mapped by Doctrine, so it cannot be validated for uniqueness
One cause is using FOS\UserBundle\Model\User as BaseUser and running doctrine schema:update, if you did this you create a table on a database without several columns like username, usernameCanonical, password, etc.
When you want to access to any functionalities of this you get that message.
How to fix:
Dropping table fos_user on database
Change FOS\UserBundle\Model\User as BaseUser
to
FOS\UserBundle\Entity\User as BaseUser
Run php app/console doctrine:schema:update --force
I am using Symfony-2.0 and Propel 1.6.
For testing purposes I'd like to have separate schema file. The reason is that with my current schema it is impossible to load dumped fixtures, because process fails due PK and autoincrement:
app/console propel:fixtures:load --env=test
Use connection named default in test environment.
No SQL fixtures found.
No XML fixtures found.
[Propel] Exception
Cannot insert a value for auto-increment primary key (article.ID)
If I could define test_schema.xml I'd generate models from it without autoIncrement="true" property and then fixtures would be loaded.
How can I force Propel to use test_schema.xml in test environment?
Or may be there is another way how to load fixtures correctly?
You can use the propel propel.schema.dir and propel.default.schema.basename build properties to specify where the schema file is located and its name:
# app/config/config_test.yml
propel:
build_properties:
# The directory where Propel expects to find your `schema.xml` file.
propel.schema.dir = //wherever
# The schema base name
propel.default.schema.basename = schema