I was looking for a built-in method to urlize/slugify a string, instead of copying a strandard one found on google.
Thus I found this : http://sourcecookbook.com/en/recipes/59/call-the-slugify-urlize-function-from-doctrine , referencing to this Doctrine Class http://www.tig12.net/downloads/apidocs/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Doctrine_Inflector.class.html , with the method urlize() which is exactly what I'm looking for.
But, in my Doctrine Bundle from Symfony 2, in \vendor\doctrine\common\lib\Doctrine\Common\Util my Inflector class is pretty empty.
What happened to this urlize() method ? Do I have to recode it ?
There's https://github.com/Behat/Transliterator which includes the urlize function from Doctrine1
This is the part taken from Doctrine 1.2.3
Doctrine inflector has static methods for inflecting text
You could just composer require behat/transliterator
and have a HelperClass extending Behat\Transliterator.
And then be able to do: MyStringHelper::urlize("isn't that great?")
The file you are looking at (Doctrine\Common\Util\Inflector) is supposed to be used internally by Doctrine, to convert between table names (underscore separated), property names (camelCase), and class names (CamelCase).
What you are looking for can be achieved with the sluggable doctrine extension. You can ingtegrate it easily into a symfony2 application with stof/StofDoctrineExtensionsBundle.
Related
Without scrutinizing why I want this (it may sound like a bad approach, but I have good reason) I want to know if there is a way in the standard-framework-edition 3.1+ to create a relational association to an entity that may not exist...
Firstly I do realize this determines the schema and that's fine. So if an entity does not exist, it doesn't create a foreign key and the field is always null, or if the target entity does exist, it creates the foreign key and the field works like a normal association...
Secondly, this only changes project to project, and may change down the line as an update to which I realize a manual schema update could be necessary.
Preferably without 3rd party bundle dependencies... hoping for the standard framework to do this,
Anybody?
Thanks in advance
Edit
I am using annotations in my entities with doctrine ORM
Furthermore
The simplest version of why I am doing this is because certain bundles are optional project-to-project, and bundle A may make use of entities in bundle B only if it is present. I have considered using services and if container->has then container->get, or the XML on-invalid="null" approach, but that doesn't address property persistence. I was happy with storing a non-mapped value as a custom relational field, which is fine, just lengthier and wondered if perhaps there was a way Doctrine could ignore a missing targetEntity...
Hm, perhaps I misunderstand your question, but this sounds like a normal 'nullable' association to me?
Create your assocation via annotation:
/**
*
* #var Child
* #ORM\ManyToOne(targetEntity="Child")
*/
private $child;
and use
setChild(Child $child = null)
{
$this->child = $child;
}
as a Setter to allow nullable values.
And your getter might look like:
getChild()
{
return $this->child;
}
In case there isn't any child it will return null.
I will keep the other answer as it responds to the question for a 'nullable association target' live data.
This is the answer for a 'nullable association target' meta data which is a different thing.
OP asks to provide a targetEntity in the metadata which cannot exist in his case, e.g. is not there in a different bundle (or whatever OP's mysterious reason might be).
In that case I recommend to build upon Doctrine's TargetEntityListener which is able to resolve the targetEntity during runtime and targetEntity can be set to an Abstract Class or an Interface:
/**
* #ORM\ManyToOne(targetEntity="Acme\InvoiceBundle\Model\InvoiceSubjectInterface")
* #var InvoiceSubjectInterface
*/
protected $subject;
InvoiceSubjectInterface will then be replaced during runtime by a specific class provided by config e.g.:
# app/config/config.yml
doctrine:
# ...
orm:
# ...
resolve_target_entities:
Acme\InvoiceBundle\Model\InvoiceSubjectInterface: AppBundle\Entity\Customer
So this should be eiter an extendable behaviour for providing no class or implementing an own solution.
I'm using this official tutorial to generate entityies from database, all works well except db column comments they are totally missing.
When i run this mapping import command in xml i see column comment
php bin/console doctrine:mapping:import --force AcmeBlogBundle xml
right after running
php bin/console doctrine:mapping:convert annotation ./src
when i open Entity/SomeTable.php some_column (which had comment in database) dose not have options={"comment":"some comment"} in annotation
So do i miss some option for convert command or it is bug of doctrine/symfony and is there a solution for this ?
Note: i have tested this with both symfony2 and symfony3 issue is same
Currently there is no option that will convert your comments and add it to the entity class. The Entity geneartion can be seen in the DoctrineBundle of Symfony in the class Doctrine\ORM\Tools\EntityGenerator this class says it all:
Generic class used to generate PHP5 entity classes from ClassMetadataInfo instances.
So in easy words the mapping you create in xml is then read as ClassMetadataInfo and the EntityGenerator generates the entity class from that ClassMetadataInfo. If you want you can try to add an implementation for the comment or propose a PR or bug in the symfony git repository.
See generateFieldMappingPropertyDocBlock method of the Doctrine\ORM\Tools\EntityGenerator class and see if you can manage to understand the code and add your comment from there.
Based on #SimeonKolev answer i was able to implement simple fix for this issue in doctrine/orm/lib/Doctrine/ORM/Tools/EntityGenerator.php to have options={"comment"=".."} filled in each Entity
Solution was add in EntityGenerator.php method generateFieldMappingPropertyDocBlock before if (isset($fieldMapping['unsigned']) ... condition near to ~1652 line
if( isset($fieldMapping['options']) && is_array($fieldMapping['options'])
&& isset($fieldMapping['options']['comment']) ){
$column[] = 'options={"comment"="'.$fieldMapping['options']['comment'].'"}';
}
I want to use doctrine migrations in my non-symfony project, so I got the phar standalone from https://github.com/doctrine/migrations. I configured everything properly (db-configuration and configuration) and then when doing "migrations:status" I get the error:
[Doctrine\DBAL\DBALException]
Unknown database type enum requested,
Doctrine\DBAL\Platforms\MySqlPlatform may not support it.
Now there are many resources on how to fix this in the context of a symfony app (for instance http://wildlyinaccurate.com/doctrine-2-resolving-unknown-database-type-enum-requested) but where can I put this type mapping in this case? Should I extract the .phar, put the code in it (where?) and then re-package it? (how?)
I have tried something for Zend framework and it worked:
Open ./vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php
Search for function initializeDoctrineTypeMappings()
create an entry for enum as,
'enum' => 'string'
Worked like charm !
That problem resolved in this fork
https://github.com/dyadyavasya/migrations
By default Doctrine does not map the MySQL enum type to a Doctrine type. This is because Enums contain state (their allowed values) and Doctrine types don’t.
Use fork at link and you can register MySQL ENUMs to map to Doctrine strings.
This way Doctrine always resolves ENUMs to Doctrine strings.
migrations.yml
name: Doctrine Sandbox Migrations
migrations_namespace: DoctrineMigrations
table_name: doctrine_migration_versions
migrations_directory: /path/to/migrations/classes/DoctrineMigrations
mapping_types:
enum: string
More information - https://github.com/dyadyavasya/migrations#migrationsyml
What Ocramius said:
You need to use migrations and setup the CLI on your own. Start from cloning github.com/doctrine/migrations and installing via composer. After that, customize your CLI runner to setup the connection according to your own needs.
I am trying to mix doctrine 2 along with Zend framework, and I am using Zend auto loader. so All my Entities is looked like
TEST_ORM_Entities_User under TEST/ORM/Entites/User.php
but there is a problem with serialization since all proxies will look like
Pocks\ORM\Proxies\TEST_ORM_Entities_UserProxy under TEST/ORM/Proxies/TEST_ORM_Entities_UserProxy.php
So doctine can't find my proxy classes, and when I check my cache I found it corrupted
object(__PHP_Incomplete_Class)#175 (19) {
["__PHP_Incomplete_Class_Name"]=>
string(46) "TEST\ORM\Proxies\TEST_ORM_Entities_UserProxy"
Any Idea how we can explicitly put the Proxy File Name, or solving this issue?
We ran into the same problem in the past, and ended up converting our application to use namespaces as well.
We still use Zend Framework 1.x and its pseudo-namespace convention, but all of our application classes are namespaced thanks to this fix.
Now our code looks like:
<?php
namespace Application\Form;
use Zend_Form as Form;
class UserForm extends Form
{
// ...
}
And we can refer to this class by Application\Form\UserForm anywhere in the code, thanks to the autoloader fix!
I created yaml configuration for Doctrine. When I'm trying doctrine orm:generate-entities, it creates php files with getters and setters in camel case. So, is_public field transforms into setIsPublic and getIsPublic methods. It's owful. How can I get set_is_public and get_is_public? I can manually edit generated php files, but I don't know what will happen when I change the schema.
You can choose a naming strategy that Doctrine will use to generate the items using:
Using a naming strategy you can provide rules for automatically
generating database identifiers, columns and tables names when the
table/column name is not given. This feature helps reduce the
verbosity of the mapping document, eliminating repetitive noise (eg:
TABLE_).
For your specific case, I think you're looking at something like:
$namingStrategy = new \Doctrine\ORM\Mapping\UnderscoreNamingStrategy(CASE_LOWER);
$configuration()->setNamingStrategy($namingStrategy);
The linked topic goes on to show you how you can write your own custom naming strategy.
If you're using Symfony, it's even easier (like most things are with Symfony, but that's just my opinion) via config.yml:
doctrine:
orm:
naming_strategy: doctrine.orm.naming_strategy.underscore
Symfony's coding standards encourage Symfony users to use camelCase:
Naming Conventions
Use camelCase, not underscores, for variable,
function and method names, arguments
Personal advice - do not generate entities by doctrine orm:generate-entities.
Use plain PHP to create class. Why?
Orm uses reflection on privates to communicate with database. You dont need to generate setters and getters. I recomend You to use design patterns such as factory or constructor to achive Your goal. Decorators also should work fine.
<?php
class MyClass
{
private $id;
private $name;
public function __construct(int $id, string $name)
{
$this->id = $id;
$this->name = $name;
}
}
$camelCase is not only Symfony's recomendation for code standard. It's based on PSR2. I highly recomend using PSR2, code gets clean and standarized.
Standard ORM naming strategy is $camelCase private var to snake_case column name. If you want to change it otherwise, consider: other naming stategies