Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-20 Thread [EMAIL PROTECTED]
Malcolm Tredinnick wrote: > On Thu, 2006-07-20 at 02:25 +, DavidA wrote: > > But why not let the backend decide the best way to build the ALTER > > TABLE/ADD CONSTRAINT statement? Then the MySQL backend could leave them > > unnamed, avoiding the uniqueness/length issues, and other backends > >

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread DavidA
Malcolm Tredinnick wrote: > > That is also possible, but I was trying to avoid another reliance on the > backend (things like "sqlall" start to get complex). Still, it's > probably only a single proxy function call, so not too hard to maintain. > > I'm sure if I keep coming up with bad implementa

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread Malcolm Tredinnick
On Thu, 2006-07-20 at 02:25 +, DavidA wrote: > > Malcolm Tredinnick wrote: > > I was trying to avoid a hash-based solution because it leads to > > unreadable names (and I don't think every database supports unnamed > > constraints, so that isn't a universal solution, either). I need to do a >

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread DavidA
Malcolm Tredinnick wrote: > I was trying to avoid a hash-based solution because it leads to > unreadable names (and I don't think every database supports unnamed > constraints, so that isn't a universal solution, either). I need to do a > bit of research and them come up with a legal hash constru

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread Malcolm Tredinnick
On Thu, 2006-07-20 at 00:39 +, DavidA wrote: > > Malcolm Tredinnick wrote: > > On Wed, 2006-07-19 at 11:24 +, DavidA wrote: > > > MySQL requires each constraint to have the same name. > > > > I'm pretty sure you meant to say "different name" there. :-) > > Oops. I guess that's what the "

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread DavidA
Malcolm Tredinnick wrote: > On Wed, 2006-07-19 at 11:24 +, DavidA wrote: > > MySQL requires each constraint to have the same name. > > I'm pretty sure you meant to say "different name" there. :-) Oops. I guess that's what the "preview" button is for. > The problem should be fixed in r3373

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread Malcolm Tredinnick
On Wed, 2006-07-19 at 11:24 +, DavidA wrote: > > Alexis Smirnov wrote: > > ALTER TABLE `console_restoreevent` ADD CONSTRAINT > > `identity_id_referencing_console_identity_id` FOREIGN KEY (`identity_i > > d`) REFERENCES `console_identity` (`id`); > > ALTER TABLE `console_backupevent` ADD CONST

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-19 Thread DavidA
Alexis Smirnov wrote: > ALTER TABLE `console_restoreevent` ADD CONSTRAINT > `identity_id_referencing_console_identity_id` FOREIGN KEY (`identity_i > d`) REFERENCES `console_identity` (`id`); > ALTER TABLE `console_backupevent` ADD CONSTRAINT > `identity_id_referencing_console_identity_id` FOREIGN

Re: avoiding ADD CONSTRAINT in management.syncdb()

2006-07-18 Thread Malcolm Tredinnick
On Tue, 2006-07-18 at 22:16 -0400, Alexis Smirnov wrote: [...] > Questions: > - Any idea why MySQL 5.0.20-nt does't like above SQL? You've hit the same bug that David Avraamides posted about on this list last Saturday (see the tread titled "Syncdb generates non-unique foreign key constraints").

avoiding ADD CONSTRAINT in management.syncdb()

2006-07-18 Thread Alexis Smirnov
The following model:class Release(models.Model):    name = models.CharField(maxlength=128)class Software(models.Model):    name = models.CharField(maxlength=128)    release      = models.ForeignKey(Release, null=True, blank=True) class Hardware(models.Model):    name = models.CharField(maxlength=12