austgl / mysql-workbench-doctrine-plugin

Automatically exported from code.google.com/p/mysql-workbench-doctrine-plugin
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Relationships not being set in database #41

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.import the attached workbench project
2.generate schema file
3.build database, for instance MembersAddress has relationship but
membersauth doesn't most relationship fail

What is the expected output? What do you see instead?
Relationships would be as defined in the workbench err

What version of the product are you using? On what operating system?
TRUNK

Please provide any additional information below.
The workaround I used to solve this issue is adding 

relations = relations .. "      owningSide: true\n"

on line 832

I know at one point this was working correctly but I am not sure if its a
design issue/naming issue on my part or something missing in the declarations.

My trancing leads me to doctrines Relation/Parser.php 209 it seems even
localkey index's are being classified as foreignkeys. I think it is
probably an issue I'm introuducing but haven't figured it out.

Since we generate only on the owning side adding the owningSide identifier
seems to have resolved it

Original issue reported on code.google.com by Jason.Br...@gmail.com on 3 May 2010 at 6:39

Attachments:

GoogleCodeExporter commented 9 years ago
These are the options that are set:

-- #############################
    -- ##  CUSTOM CONFIG OPTIONS  ##
    -- #############################
    _G.locConfig = {
      enableCrossDatabaseJoins            = false    -- default false| true (for
further information see blog post on
                                                     --
http://www.doctrine-project.org/blog/cross-database-joins )
      ,defaultStorageEngine               = "InnoDB" -- default InnoDB|MyISAM
      ,enableStorageEngineOverride        = false    -- default false|true
      ,enableOptionsHeader                = true     -- default true|false (enable
header output)
      --,enableRenameIdColumns              = true     -- default true|false
(detect_relations feature of doctrine)
      ,enableRenameUnderscoresToCamelcase = true     -- default true|false (enable
table_name -> tableName)
      ,enableRecapitalizeTableNames       = "first"  -- default first|all|none
      --,enableSingularPluralization        = true     -- default true|false
      --,enableShortFormatting              = false    -- default false|true
      ,preventTableRenaming               = false    -- default false|true
      ,preventTableRenamingPrefix         = "col_"   -- default "col_"
      ,alwaysOutputTableNames             = true   -- default false|true (always add
tableName: to table definition)
      ,sortTablesAlphabetical             = false    -- default false|true
      ,useReferencenamesAsRelationnames   = false    -- default false|true
    }

Original comment by Jason.Br...@gmail.com on 3 May 2010 at 6:40

GoogleCodeExporter commented 9 years ago
Thank you for this report.

But I have to admit that i'm unable to figure out why this problem occurs. I 
was also
not aware of the "owningSide" option - and i'm not certain that i understand it 
in
particular.

If the owningSide option solves your problem we may should add this option in 
general
to the yml models. Do you think there will be unintended side effects?

Johannes

PS: If you are interested in contributing code to this project i can give you 
svn-access.

Original comment by johannes...@gmail.com on 3 May 2010 at 8:56

GoogleCodeExporter commented 9 years ago
The owning side tells Doctrine which table to create the foreign key on, from 
the docs:

Set to boolean true to indicate the owning side of the relation. The owning 
side is
the side that owns the foreign key. There can only be one owning side in an
association between two classes. Note that this option is required if Doctrine 
can't
guess the owning side or it's guess is wrong. An example where this is the case 
is
when both 'local' and 'foreign' are part of the identifier (primary key). It 
never
hurts to specify the owning side in this way.

I wasn't able to track it down either, from what I can tell in workbench we 
always
create the foreign key on the owning side as thats how workbench. I don't see a 
side
effect of setting it by default but I have only used it on this one project.

As for contributing I'd love to but have no experience coding in LUA I just was 
able
to guess it from your coding.

Cheers,

Jay

Original comment by Jason.Br...@gmail.com on 4 May 2010 at 1:22

GoogleCodeExporter commented 9 years ago
there are still some tables that don't get their foreign keys, like Domains 
table has
no foreign keys associated, It seem to resolve some but not all. I'll have to 
dig
into this further

Original comment by Jason.Br...@gmail.com on 4 May 2010 at 2:35

GoogleCodeExporter commented 9 years ago
Tracked it down,

Changing this:

if( foreignKey.many == 1 ) then
          relations = relations .. "      type: many\n"
        else
          relations = relations .. "      type: one\n"
        end        

to foreignType

if( foreignKey.many == 1 ) then
          relations = relations .. "      foreignType: many\n"
        else
          relations = relations .. "      foreignType: one\n"
        end        

resolves 90% of the relationships adding the owningSide declaration resolves the
remaining 10% in my database.

Cheers,

Jay

Original comment by Jason.Br...@gmail.com on 4 May 2010 at 3:30

GoogleCodeExporter commented 9 years ago
Thank you for tracking this down. I will change the code and hope this causes 
no side
effects.

Johannes

LUA is just the name of a language - it doesn't mean, that you can not code 
(see your
comment above). As always, there are just a few words which are different from 
other
languages.

If you think your contributions/suggestions will be helpful for having a better
quality for the plugin don't hesitate to contact me. What I feel is that we are
missing someone who uses the plugin for every day work and has some expertise in
doctrine - which is not the case for me or any of the developer.

Original comment by johannes...@gmail.com on 4 May 2010 at 5:56

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r116.

Original comment by johannes...@gmail.com on 4 May 2010 at 8:40

GoogleCodeExporter commented 9 years ago
Hey Johannes,

Thanks I will help out as I can, I just started with Doctrine 2 weeks ago so I 
am no
expert although I tend to dive into things and get familiar pretty quick.

I will keep an eye for issues I may help with and try to contribute ideas as 
well.

Cheers,

Jay

Original comment by Jason.Br...@gmail.com on 4 May 2010 at 2:59