Question

One problem I always ran into with ORMD1 and using a custom columnDefinition is that "NOT NULL" and the likes have to be duplicated in the columnDefinition. That is, you have to provide the complete columnDefinition and once you do, the checkboxes on a property don't have any meaning except as a visual indicator. The model designer needs to check these for consistency and that's error-prone.

What if columnDefinition could be something like "BIGINT UNSIGNED" or "ENUM('a','b','c')" and other parts of the definition would be added by ORMD automatically, according to the settings in the GUI?

Answer 1

After a short discussion with my colleague we came to the conclusion that implementing of this feature could cause more harm than good.

• One reason is in case of existing values, when ORMD should check if field already doesn't contain such value (NOT NULL,...).
• Second reason that these keywords should be DB dependent, so there is no strict rule what kind of value insert to column definition.
• Next reason is custom keyword positioning, so ORMD also should have correct keyword-order generator, maybe inserting to the middle of existing string.
• Also how to decide which keywords add and which not? Because after all the generator should generate the whole string, instead of appending only some values (which is what Doctrine do)
• The last complication is that all of this would be implemented in XSLT layer because it's strictly Doctrine dependent.

Because of that we think it's a not good idea to do that. But on the other side, maybe there is another way how to help you with this task. What is the reason why you need to define each definition manually instead of letting Doctrine to generate a field definition itself?

Comments

I see your point(s).

For example ENUMs or UNSIGNED columns. Doctrine is so database-independent that it does not even support these things, but some developers that are used to MySQL only and not to any ORM sometimes wonder why we can't use these.
It's not crucial and I can live with the current state of things (really only the NOT NULL property you need to take care of).

Edit: Maybe some checks and balances would suffice? Like a warning "you have selected this column to be not nullable, but your custom columnDefinition is missing NOT NULL declaration"?!

---

Regarding to "unsigned", you should be able to set up separate flag "unsigned" in ORM property editor:

http://screencast.com/t/6RvAIFCy

and regarding to enum, ORM Designer supports enum directly:

http://screencast.com/t/BTf19JX2

If anything of these things doesn't work, please let me know and we will fix it.

---

Sweet! That's basically all I need! One more reason to quickly switch to ORMD2. ;)

I did not specifically look for these features in the new version because they weren't there in ORMD1 but I will definitely test these now! Thanks for the hint!

---

I have to aggree that quick switch to ORMD2 is a great choice because of lot of improvements. But in this case both of these features were already available also in ORMD1 ;-).

http://screencast.com/t/O0ArF0eXTuI

---

Okay, maybe we're talking about different things here. I have a Doctrine2 model in ORMD1 and that does not feature these properties.

Just confirmed: Doctrine 2 model does not feature ENUM and UNSIGNED in ORMD2. :-(

---

Oh, I missed you're talking about Doctrine2. I checked it and you're right. ORMD doesn't offer a way how to define unsigned or enum to D2 because D2 doesn't support them.

Maybe the solution could be in custom extending D2 generator for enum and unsigned property and then also extend ORMD D2 definitions (this will be probably the easier part).