I have a mysql database table called UserDegree, when i try to import back to PHP using Doctrine it generates a model name Userdegree, is there a way to solve this?
i really can't find any good doctrine documentation.
thanks!
I am not sure about your specific problem, but for the "good doctrine documentation" part, did you try the manual ? See Doctrine ORM for PHP -- I think it's actually quite good, especially compared to what you get with some other projects, that don't have much documentation, or totally outdated.
About your problem (as I said before, not sure) : I suppose Doctrine takes each "word" from the table name in the DB, and converts that to a "name" for PHP. Quite often, "words" in table names are separated by an underscore '_', and are all in either lower or either case.
I suppose, if you name your table "user_degree", instead of "UserDegree", that Doctrine should detect it's composed of two "words", and create a PHP class called "UserDegree" -- actually, I tested with a table called post_has_tag, and it generates a class called PostHasTag.
Pascal Martin is correct. The table should be named like user_degree, in this case Doctrine will generate UserDegree class.
I also recently figured out that it is possible to keep all database identifiers to be under_scores, while having Doctrine to generate camelCase'd code. It happens automatically for table names, as said above. As for field names, they can be mapped to camelCase using alias feature of YAML schema file (name: user_id as userId). Moreover, you can automate field aliasing by developing custom task for Doctrine.
Related
I was given this project to work on with absolutely no documentation or contact developer. I noticed in the database dump that they are storing what looks like PHP Namespaces for Eloquent models in a couple tables. For example an address table has a string column named "object_type" with the value always being "App\Entities\Client". I searched through the whole project for the PHP code that would use this value. Hopefully to give me insight to it's purpose. Not to my surprise, the project never uses this value. I just see it hard-coding these values upon insert into the DB.
My question is, is this some sort of Database and/or ORM modeling design practice? If so, could you explain how this could be used in a simple practical sense?
Maybe this was some concept the developer had and it never evolved. It's interesting idea but, the idea of joining through MySQL on a string conditional sounds like torture.
Sounds like Laravel polymorphic relationships:
Custom Polymorphic Types.
By default, Laravel will use the fully qualified class name to store the type of the related model.
And, yes, this is a valid modeling technique, though purists rightly argue this technique abuses normal form.
I am not sure what the developers where thinking.
But imagining we are in a forum with thread and replies to each thread. We maybe want to have a Favourites table where we can save replies and threads.
A way to do it would be to have a column in the favourites table called "object_type" (just to use the same term you have in your case) and then when we save an object into the database with eloquent we can use:
$favourite->object_type = get_class($thread); //or get_class($reply) in case we want a reply
$favourite->save();
This way will save the namespace of that class into the database. But laravel will recognise it when we get it from the database.
Hope this cold be helpful.
I've now read kinda half of the Doctrine 2 documentation but I can't find a solution: how do I create a table for a class automatically using Doctrine?
Do I really need to work with XML/YAML or some other stuff than PHP itself? Do I really need DQL for that? Doesn't Doctrine find the names and all this stuff for me?
First of all, you have to understand that in Doctrine 2 there are three elements that play together:
entities (just plain PHP classes)
mappings (additional markup that you place on entities or in related classes)
database
Doctrine reads your entities and your mappings and connects every entity and its fields to the related database fields.
The generation of the database is done by the Doctrine\ORM\Tools\SchemaTool (SchemaTool) class, which can read metadata and define how your schema should like.
Doctrine's CLI, as said by #Marcin, provides the orm:schema-tool:create and orm:schema-tool:update commands, which are just wrappers for the SchemaTool. They help you getting started fast and keep your schema in sync with your entity definitions.
I'm not sure if I understood you correctly.
If you want to create a structure in a database, use the console function orm:schema-tool:create
I have a DB (yes, that one) which is proving far easier to access via views than raw tables. In general this plays quite nicely with Doctrine, but there's one issue. Doctrine can't identify a primary key in a view table when generating the YAML from the database schema, so it invents one called 'id'. Generating classes from this means that all queries fail on the lack of this id field.
Is there any way you can hint to the generator script that it shouldn't create this field, and point it to one that's more appropriate? I can see how to do it in the YAML, or in a class with annotations, but no way to do it in the DB.
Suggestions welcome.
(Anyone following my questions (why?) will probably have worked out how much fun I'm having with both Doctrine and this database. I think it's called a "learning experience".)
I have no idea how to do it in the YAML but you can just remove the the definition of the ID column from the generated PHP (Base) file. Not the most "elegant" solution but I think Doctrine's convetnion is to always add a Primary Key.
BTW, is there anything usefull for you at http://www.doctrine-project.org/projects/orm/1.2/docs/manual/component-overview/en#views?
perhaps not exactly what you asked but
another solution is to put this in the model class
public function setUp() {
Doctrine_Core::getTable('your_view_name')->removeColumn('id');
parent::setUp();
}
hope it helps someone with this problem
This isn't much of an issue with MySQL per-se.
The Full Story
I'm writing a very small PHP framework. It isn't like existing frameworks where they force you to use a certain methodology. It isn't either like a CMS framework. Trust me, I've seen Zend framework and I've used CMSes like Joomla and WordPress extensively, none of them come close to what I'm doing.
Introducing The Issues
I'm writing the Database abstraction part. You get class methods like ::table_exists() etc.
It is designed in a way that people can easily add different database classes and use them instead (eg; mysql, mssql, oracle, flatfile...).
They simply need to write a class which satisfies a base abstract classes'.
The Real Issue
I'm writing the functionality for ::table_create(), but have one main problem: MySQL doesn't like empty tables (ie, without a column).
I have several proposed fixes:
For each new table, create a commonly used column, such as 'id' (type=INT)
For each new table, create a temp column which doesn't use any space as much as possible (perhaps a boolean column?)
Somehow delay table creation until at least one column can be created
This approach is most certainly new, and I'd like to here some unbiased comments about it (anything on the lines of "but no one does it that way" won't do).
Well I would either go with option 1), Adding a generic ID column, which you might find you need anyway, or with option 3) Delaying the table creation. I'm assume after they call ::table_create() they will be calling table_add_col(), etc. So just delay creation until there is at least one column, OR until they actually try and use the table for the first time.
Your proposed fixes look quite good. But I would recommen them in a diffrent order. If you are able to delay the creation, tht's probably the best. My second favorite would be to have a table with only an ID, although you might be delete this column, if you want to create a many-to-many relations table with two foreign keys only.
last of your points.
its really very strange what you are doing here. creating tables on the fly? dynamically or something?
well... whatever you are trying to accomplish. you should have a look at document/object oriented databases like couchdb http://couchdb.apache.org/ ! you can create a document and dynamically add whatever fields you want. those are the closest thing to your "columns"
but as you like it...
your first attempt is ugly because it might lead to conflicts.
the second attempt is clumsy. but if you do so create a col with uniqueprefix_random so you can delete it afterwards.
but its well... i dunno what to say about that.
theird approach seems the only senseful!
Just getting started with Doctrine ORM for PHP (v1.1.5) and ran into something unexpected.
I am generating models from the db (MySQL 4) using:
Doctrine::generateModelsFromDb($pathToModels);
Then generating YAML from the models using:
Doctrine::generateYamlFromModels($pathToSchema . '/schema.yml', $pathToModels);
In the generated models, the column names (as defined in hasColumn()) use the same case for the fields as in the db. All good.
But in the generated YAML, the column names are all lower-case, irrespective of the case in the model.
There do not seem to be any options available on the generateYamlFromModels() method that I could conceivably use to tweak this. Is there some other attribute I should be setting someplace, perhaps at connection-level, or at manager-level, etc? Might it be a bug?
Any ideas greatly appreciated. Thanks and cheers!
It seems this is a bug. I say that because YAML is case sensitive, and Doctrine's generateYAMLFromModels() is documented to be case sensitive. I did find a case sensitivity bug that was in 2.0 beta. Maybe this is the bug that affected your program. Barring anything else, though, it looks like Dimitris Baltas' comment seems to be the the workaround of choice:
an other alternative is to generate models from DB and then yaml from models. This one keeps the right casing.
Happy Hunting :)