> OK, I've run into a snag. Schemifier does support foreign key creation, > as do most of the database vendors. The ManyToMany Mapper support, > however, seems to expect no foreign key constraints, since it's > explicitly testing broken refs in the ManyToManySpecs tests: I do not really know something about the ManyToMany stuff in mapper but in my opinion, it should support foreign keys. You always have situations where you change something in the database by hand. In such cases, it's always good to have foreign keys...
> I wonder if we should have FK generation be a configuration parameter > for schemify. I could change the code so that the default schemify > method continues to generate DDL without FK constraints, but add a > second schemify method that takes a boolean parameter controlling > whether FKs are generated. Sounds good to me > That, coupled with the > DriverType.supportsForeignKeys_?, would allow people to add FKs if they > want. Thoughts? I had the problem that when I wanted to test the foreign key support, I had to recompile most parts of lift with DriverType.supportsForeignKeys_? set to true (which was no fun because I had to download many many dependencies from the incredible slow maven repo). Wouldn't it make sense to allow setting DriverType.supportsForeignKeys_? at runtime? This would be useful when, for example, some database system does not support foreign keys when the corresponding Lift version is released but starts supporting it two weeks later. In such a situation, I do not want do recompile Lift just to have DriverType.supportsForeignKeys_? set to true... Julian -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
