0 votes

I tried Skipper from few days. Previously I used MySQLWorkbench and I made my export with mysql-workbench-schema-export and I succeed to export columns default values only with Doctrine1 format not with Doctrine2.

I don't find any options to do this.

What are your Doctrine2 export options ?


in Solved by (120 points)
recategorized by

1 Answer

0 votes

By default doctrin2 doesn't support default values. This is the reason why you don't see these values.

If I remeber correctly there is some "hacky" way how to define SQL default values by column->options->default

by Skipper developer (138k points)

Thanks for your answer. The think that disturbed me is inside Skipper the export filter is named Doctrine2 but in fact the generated file format seems to be a Doctrine1.

Can you confirm this or not ?

Export for Doctrin2 is completely different than export for Doctrine1.

It's a different format and also with different file types. Doctrine1 supports only YML and Doctrine2 supports XML,YML and PHP annotations


I suppose at the time you responded this setting could have been new or maybe undocumented, but currently it seems to be official (that's probably why it can be set in Skipper;)).

Would it be possible to extend your code generator for entity classes so that the member variables get initialized with the default values? This is exactly what the Doctrine CLI tool does if you let it regenerate the entities based on existing ones (e.g. those exported by Skipper).

Can you be more specific about what exactly you're missing in Skipper?

enter image description here
"Option" properties are already supported for several versions.

And in case that you're searching for "default" value in the options, you simply need to fill "defaul" value in fields editor:

enter image description here

and export will be

  type: entity
      type: integer
        strategy: AUTO
      type: string
      length: 255
      nullable: true
        default: xx 

I'm aware of the "default" setting, that's exactly what I'm referring to. If you set this value and let Skipper export the entity in the "Doctrine2 Annotations" format, it would be great if the resulting PHP class could use these default values for the member variables' initialization.

Let's say as a result of the export we get such a class:

 * @ORM\Entity
 * @ORM\Table(name="foo")
class Foo
     * @ORM\Column(type="boolean", nullable=false, options={"default":true})
    private $visible;

What I'm missing is the following initialization:

private $visible = true;

I'm new to Doctrine and am in the process of figuring out which workflow including Skipper and (perhaps) Doctrine CLI tool works for me.

If I see it right, at the moment, after exporting the entities by Skipper, I have to make the initialization manually, otherwise the member variables can have different values as the defined defaults.

What bothers me is the period after creating an entity object until it gets persisted for the first time - if I have member variables which are not initialized, forget about the manual initialization and use the object, my object's "state" is not what you would expect after defining the default values. I guess you can already see what I'm getting at...

The doctrine CLI tool doesn't solve the problem either, since it "only" lets you generate the mutators when updating the entity class (I purposely avoid regenerating the classes, since it removes the custom logic out of the class,... but it also adds the member variable initialization as shown above).

Ok, I understand now.

Unfortunately what you're referring to isn't possible right now. The reason is that as soon as we export default value for the first time, users will automatically assume that we will also update the default value after any future change.

Currently, Skipper updates only @ORM annotations, nothing else to not damage user codebase. What you're referring to is updating PHP code, not @ORM annotations.

On the other side, with the new upcoming Php standard it will be possible to define member property types. And this will be the same situation as with default values.

We will probably be forced to implement also updating PHP code to be able to update exported datatypes also to variables. In case we will decide to implement it we will be also able to export default values directly to Php code.

I can't promise any exact ETA but if possible we will implement datatypes together with default values.

"[...] The reason is that as soon as we export default value for the first time, users will automatically assume that we will also update the default value after any future change."

Well, that's what I would actually expect. As far as the PHP code generation is concerned, what would be otherwise the motivation or a use-case for defining a default value?

When I do it, I want this value to be always used for the initialization, not only once. Otherwise the advantage of not having to remember about initializing the member variables would disappear. Just my 2 cents:)

Yes, and this is exactly the reason why we're not exporting the default values now ;-)).

It's because Skipper is ORM tool, not Php code generator. And as ORM tool, we're exporting only ORM properties, originally only to XML and YML. After that, Doctrine2 introduces annotations, so we updated exporters to work only with annotations.

On the other side, what you're describing is Php code manipulation what is a slightly more complicated because there can be a lot of user code.

This is also a reason why when you remove ORM property, Skipper NEVER remove such property from your code. Skipper only remove @ORM annotation. It's becuase you can still want to use such property from your code but you don't want to be serialized.

And Php default values/types is the same. You could (for whatever reason) want to have different type/default values than in ORM. In case we would be 100% consistent, we would never touch Php code ;-)