(Sorry I've taken so long to reply to this, it fell through the cracks.) On 9/18/06 7:47 AM, James Masters wrote: > If I define a relationship from table1 to table2, do I also need to define > the reverse relationship from table2 to table1?
No. > I have changed my table names and field names to match the default > conventions, in the hope that this would minimise my work. In particular I > was hoping that it would mean that the Loader would be able to work out and > define my relationships, even though I am on MySQL. It doesn't seem to do > this. Is this because I was hopelessly optimistic or because I've done > something wrong? [Actually, the more I think about this question, the more > I believe that the Loader couldn't sort out many_to_many relationships but > perhaps the other 3 types should be possible?] The Loader will only discover relationships that are indicated in some way by the metadata in the database. The column names alone cannot tell it that a relationship exists. Actual foreign keys in the database are required. MySQL can do this, but not with the MyISAM storage engine. You must use the InnoDB storage engine (or other engine that supports foreign keys.) Even with the InnoDB storage engine, there are some more hoops to jump through. MySQL is quite capricious :) Here's a link to an earlier mailing list post describing how to put enough metadata in a MySQL database to enable the Loader to find the relationships: http://www.mail-archive.com/rose-db-object@lists.sourceforge.net/msg00929.ht ml In the example you'll see that the Loader can indeed find and create many-to-many relationships, even when using MySQL. > I am rather amateur when it comes to OO methodology. If I don't use Loader > to define my table classes, then it appears that I have to create a whole > load of .pm files, one per table. Or if I do use Loader, then I have to > create a directory and an Extra.pm file for each table (for MySQL > relationships). My experience with performance is miminal but in my > travels, I have noticed that one of the worst things for it is opening and > reading files. However, I see that some documentation examples seem to show > multiple packages being defined within a single .pm module. This might just > be the way the documentation is written to avoid too much clutter, though - > not sure. Is it feasible to replace all those table .pm files or the > Extra.pm files with a single .pm file? As others have already said, it's generally a good practice to keep to the traditional "one file, one package" setup. Yes, reading many .pm files may be ever-so-slightly slower, but runtime performance is usually more important than startup time. (And if you need really, really fast startup time, arguably you shouldn't be using Perl :) So yes, you can put many packages into the same .pm file if you do it carefully enough and understand all the moving parts, but the trade-off in clarify and maintainability is not worth it, IMO. -John ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
