[mysql-wb-doctrine-plugin:4] OptionsInTableComments

[Robert Cesaric]

Hi Johannes and everyone,

I have a dilema. I'm playing around with the Options in Table
Comments. I'm getting a "ERROR: Error 1628: Comment for table ...
too long". I didn't realize MySQL has a 60 character limit on table
comments when synching. Maybe helpful to make a note of that on the
Wiki for the users that are also using WB to not only create the YAML
but synch their DB too.

I'd be interested in hearing feedback in regards to shortening the
option definition as such:

{d:actAs}
...
{/d:actAs}

I'm over the character limit but not by much. Every few characters
help when you're restricted to 60. As an FYI, column comments have a
255 char limit and the schema comment don't appear to be effect
Workbench on DB pushes.

On a similar note, I'm working on aerial-project.org and have modified
the WB-Doc plug-in to read in the following option in the schema
comment:

{doctrine:package}
mapClass: model.vo
{/doctrine:package}

The reason for this is that Aerial uses a slightly modified version of
Doctrine where a "mapClass" property needs to be defined for each
table in the YAML. I was originally able to achieve the mapClass
property w/o hacking by using the {doctrine:actAs} option in the table
comment but character limits described above eventually just forced me
to move it out to the schema comment.

Thoughts on possibly adding the doctrine:package option or similar to
the project which would add the defined property to each table in the
YAML? If so, I can forward my Lua script.

Thanks!

[Johannes Mueller]

On 7 Mai, 19:52, Robert Cesaric <rcesa...@gmail.com> wrote:
> Hi Johannes and everyone,
>
> I have a dilema.  I'm playing around with the Options in Table
> Comments.  I'm getting a  "ERROR: Error 1628: Comment for table ...
> too long".  I didn't realize MySQL has a 60 character limit on table
> comments when synching.   Maybe helpful to make a note of that on the
> Wiki for the users that are also using WB to not only create the YAML
> but synch their DB too.

You mean, when you create your database from workbench you get these
errors, because of the 60 char limit? I have never tried to do that,
because the plugin is intended to create the database with doctrine,
not with workbench. Or are you not allowed to store more than 60 chars
in the comment - than you should try a newer version of workbench.

> I'd be interested in hearing feedback in regards to shortening the
> option definition as such:
>
> {d:actAs}
>   ...
> {/d:actAs}
>
> I'm over the character limit but not by much.  Every few characters
> help when you're restricted to 60.  As an FYI, column comments have a
> 255 char limit and the schema comment don't appear to be effect
> Workbench on DB pushes.

When we can implement this without breaking backwards compatibility
this would be possible, even it does not solve the problem at all.

> On a similar note, I'm working on aerial-project.org and have modified
> the WB-Doc plug-in to read in the following option in the schema
> comment:
>
> {doctrine:package}
>   mapClass: model.vo
> {/doctrine:package}
>
> The reason for this is that Aerial uses a slightly modified version of
> Doctrine where a "mapClass" property needs to be defined for each
> table in the YAML.  I was originally able to achieve the mapClass
> property w/o hacking by using the {doctrine:actAs} option in the table
> comment but character limits described above eventually just forced me
> to move it out to the schema comment.

Where exactly is this plotted in a real world example. I don't care if
this piece of code is added or not, but it is not realy related to
doctrine. So yeah - why not, if it is helpful for you.

> Thoughts on possibly adding the doctrine:package option or similar to
> the project which would add the defined property to each table in the
> YAML?  If so, I can forward my Lua script.

If you'd like to, it would be nice to have a piece of code to ease
implementing. :)

J.

[Robert Cesaric]

On May 7, 3:19 pm, Johannes Mueller <johannes.muel...@gmail.com>
wrote:

> On 7 Mai, 19:52, Robert Cesaric <rcesa...@gmail.com> wrote:
>
> > Hi Johannes and everyone,
>
> > I have a dilema.  I'm playing around with the Options in Table
> > Comments.  I'm getting a  "ERROR: Error 1628: Comment for table ...
> > too long".  I didn't realize MySQL has a 60 character limit on table
> > comments when synching.   Maybe helpful to make a note of that on the
> > Wiki for the users that are also using WB to not only create the YAML
> > but synch their DB too.
>
> You mean, when you create your database from workbench you get these
> errors, because of the 60 char limit? I have never tried to do that,
> because the plugin is intended to create the database with doctrine,
> not with workbench. Or are you not allowed to store more than 60 chars
> in the comment - than you should try a newer version of workbench.

Yes, it's when I create my database from workbench. It's not a
limitation of workbench but of MySQL. I tend to use the YAML to auto-
generate ActionScript files too so that's why I 1.) create my database
from workbench 2.) generate the YAML 3.) then generate my Doctrine &
AS3 files (AS3 files are generated using Aerial via the YAML).

>
> > I'd be interested in hearing feedback in regards to shortening the
> > option definition as such:
>
> > {d:actAs}
> >   ...
> > {/d:actAs}
>
> > I'm over the character limit but not by much.  Every few characters
> > help when you're restricted to 60.  As an FYI, column comments have a
> > 255 char limit and the schema comment don't appear to be effect
> > Workbench on DB pushes.
>
> When we can implement this without breaking backwards compatibility
> this would be possible, even it does not solve the problem at all.

Good point. I could code it to recognize "d" or "doctrine" for
backwards compatibility but that doesn't sit well with me as it would
make the plugin too thick with little gain. I'll think about this one
and see if I come up with a more elegant solution.

>
> > On a similar note, I'm working on aerial-project.org and have modified
> > the WB-Doc plug-in to read in the following option in the schema
> > comment:
>
> > {doctrine:package}
> >   mapClass: model.vo
> > {/doctrine:package}
>
> > The reason for this is that Aerial uses a slightly modified version of
> > Doctrine where a "mapClass" property needs to be defined for each
> > table in the YAML.  I was originally able to achieve the mapClass
> > property w/o hacking by using the {doctrine:actAs} option in the table
> > comment but character limits described above eventually just forced me
> > to move it out to the schema comment.
>
> Where exactly is this plotted in a real world example. I don't care if
> this piece of code is added or not, but it is not realy related to
> doctrine. So yeah - why not, if it is helpful for you.

Well, it would be greedy of me to have this added for just my own
purposes. Though, it could be a great addition for the community
still... For example, if you're adding actAs to every table to
implement Timestampable, it would be beneficial to the community to
have an option that they could set in the Schema Comment that would
propagate it to each table. Saves the user from having to type it in
each table comment. On that note, I could use {doctrine:actAs} in the
schema comment and still accomplish the mapClass property I'm trying
to plot.

And here's an example of the output in the case I'm using it for:

Catalog:
mapClass: model.vo.Catalog
tableName: Catalog
columns:
id:
type: integer(4)
primary: true
...
...

Product:
mapClass: model.vo.Product
tableName: Product
columns:
id:
type: integer(4)
primary: true
...
...

>
> > Thoughts on possibly adding the doctrine:package option or similar to
> > the project which would add the defined property to each table in the
> > YAML?  If so, I can forward my Lua script.
>
> If you'd like to, it would be nice to have a piece of code to ease
> implementing. :)
>
> J.

I'll email you my code in a few minutes.

Thanks for quick reply! :)

[Robert Cesaric]

Actually, I stand corrected. I would need the {doctrine:package}
option as I forgot I'm appending the table name to the package. Or an
additional table token could be implemented to keep it generic as
such:

{doctrine:actAs}
mapClass: model.vo.{doctrine:tableName}
{/doctrine:actAs}

Just a thought.