Tables ending with 'us' get changed to 'u'

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create table like 'operational_status'
2.
3.

What is the expected output? What do you see instead?
Expected OperationalStatus to be output, but instead received 
OperationalStatu

What version of the product are you using? On what operating system?
script: 0.4.0
Workbench: 5.1.18a

Please provide any additional information below.

Original issue reported on code.google.com by DaveWR...@gmail.com on 2 Apr 2010 at 8:47

[GoogleCodeExporter]

That is because of our transformation of plural table names to single table 
name php
classes.
In fact this is not an easy task because of the exceptions like "Status" which 
ends
up with an "s" which indicates the plural.

At the moment, I do not know how to solve it without a hack like for the 
behaviours,
because we recommend to name the tables in plural.

Original comment by johannes...@gmail.com on 3 Apr 2010 at 8:06

• Changed state: Accepted

[GoogleCodeExporter]

Ok, I have to explain a little more what's going on.

As you might know, we need the singular name of the table (name of the php 
class) as
well as the plural name (name as collection in relations). Normally we can have
either one or the other from the workbench models.

We decided to recommend plural table names because they represent sets of 
tuples. The
result is, that we have to convert the table names to singular. (If we would 
have
decided to recommend singular table names we would have to convert some table 
names
to plural because of the relations).

For this special case we can implement a hack, like for the behaviours and some 
other
cases like bypassed relations or you can use the config options
"preventTableRenaming" and "preventTableRenamingPrefix". If you set
"preventTableRenaming" to true the names of the tables remain the same, but your
relations will not be converted to plural also. So there is a need for the 
second
config option "preventTableRenamingPrefix" which is by default "col_" which is a
synonym for collection.

In fact you can use your php model than like this one:

Status:
  table_name: status
  id:
    type: [..]

TypeOfStatus:
  table_name: type_of_status
  id:
    type: [..]
  relations:
    ColStatus:
      [..]

If you have a better idea how to solve it, please give us a sign.

Original comment by johannes...@gmail.com on 3 Apr 2010 at 8:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm scared - i've lost the general view about the options and possibilities we
already implemented. Time to add all these to the wiki.

To fix your problem just follow these two steps:

  1. add the comment
     {doctrine:entityName}OperationalStatus{/doctrine:entityName}
  2. add the comment
     {doctrine:foreignAliasMany}OperationalStates{/doctrine:foreignAliasMany}

to your operational_status table in Workbench.

Does it fit's your needs?

I'm sorry for the confusion.

Original comment by johannes...@gmail.com on 3 Apr 2010 at 11:05

[GoogleCodeExporter]

Tables should be named in PLURAL anyway, because they are sets. People working 
with
ORM tools often misunderstand that tables aren't classes, and thus, different
singluar/plural naming conventions apply.

Original comment by kwut...@web.de on 4 Apr 2010 at 1:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

function isPlural(s)
    -- is plural if string ends with an "s" but not with "ss"
    return string.endswith(s, "s") and not string.endswith(s, "ss") and #s > 1
end

should probably become

function isPlural(s)
    -- is plural if string ends with an "s" but not with "ss", "us", ...
    return string.endswith(s, "s") and not string.endswith(s, "ss") and not
string.endswith(s, "us") and #s > 1
end

Original comment by kwut...@web.de on 4 Apr 2010 at 1:33

[GoogleCodeExporter]

@kwut...@web.de (sorry, Google is hiding your full email) - Personally, I 
wouldn't 
think the export tool should dictate the naming convention used in the tables.  
I, 
too, am of the opinion that tables should be pluralized, but it's not a battle 
I can 
win.  Therefore, I would rather the export tool handled things as follows (in 
this 
case, at least)

If we can detect that the table name in the diagram is plural, then we need the 
singular form for the class name, and we'll simply use the ucfirst name of the 
table 
in the relations for the foreignAlias.  If the table name does not appear to be 
plural, simply underscoresToCamelCase for the class name, and 
pluralize(underscoresToCamelCas for the foreignAlias name.

I think the export tool could handle cases where the tables are plural or 
singular, 
and from a users perspective, we should leave the table names intact as much as 
possible, since the user specified the names in the diagram.

Finally, the documentation on Doctrine tends to use singular names (from what I 
can 
tell), so I think it'd be best to support both cases, and not 'correct' the 
user.

I agree with comment #7 though, that is how I fixed the plugin for my situation.

Original comment by DaveWR...@gmail.com on 4 Apr 2010 at 3:00

[GoogleCodeExporter]

So we try comment #7 and this may fix the problem for the moment.

On the other hand I want to mention, that the plugin needs the plural as well 
as the
singular. I think you agree, when I say, that you want to use your php models 
like this:

$student1 = new Student(); <-- the singular of student
$student2 = new Student();

$course = new Course();
$course->setStudent($student1);
$course->setStudent($student2);
$course->getStudents(); <-- the plural of student

So this is a very simple example, why "Student" or "Students" doesn't fit at 
all. You
always need both. One to declare the php representation of the table as 
singular and
the other for the relation in "course" as plural.

To achieve this without the singular+plural information inside the workbench 
model is
impossible for every single case/word.

Original comment by johannes...@gmail.com on 4 Apr 2010 at 3:30

[GoogleCodeExporter]

Hi Johannes,

My opinion is that the export function shouldn't care what the user uses as 
convention in their table names.  The export tool should only care about taking 
the 
schema as defined in Workbench, and creating a Doctrine-compatible YAML file, 
right?  
So, we can agree that the model classes in Doctrine should be singular.  We 
also 
agree that we need both the singular and plural forms of the table names 
(Singular 
for model name, plural for foreignAliases) - so, why does the export tool need 
to 
dictate what convention should be used?  Couldn't we simply test the scenario 
where 
we need to know the form of the table?  Such that, in the case where we need 
the 
singular form, we test if the table name is plural, if it's plural, get the 
singular 
form.  If it's singular, we don't need to do anything.

It seems that if the plugin has the ability to have both forms of the table 
name, 
than we shouldn't need to force a convention on the user, since we can simply 
use the 
appropriate form, where needed.

Original comment by DaveWR...@gmail.com on 5 Apr 2010 at 2:47

[GoogleCodeExporter]

This would be great, BUT as far as I know, there is no general rule for 
figuring out
if a word is plural or singular without guessing.

I think it's better to know, that a table is (always) plural and you have to 
convert
it to singular, than knowing it could be one or the other. Even to expect the 
plural
(like now) doesn't make it easy to deal with.

Original comment by johannes...@gmail.com on 5 Apr 2010 at 3:36

[GoogleCodeExporter]

Actually, I just updated to use the latest copy from SVN - and I think the 
export may 
already work as expected.  My singular tables are left alone, and the aliases 
_appear_ 
to be pluralized as expected.  Though, now foreignAlias appears to be 
referencing the 
incorrect side of the foreignKey.

I'm not using table comments, are these now required?

Original comment by DaveWR...@gmail.com on 5 Apr 2010 at 5:19

[GoogleCodeExporter]

Original comment by johannes...@gmail.com on 14 Apr 2010 at 8:47

• Changed state: Fixed