On Thursday, June 13, 2013 1:59:16 AM UTC-7, Charlie Clark wrote: > > Am 13.06.2013, 00:42 Uhr, schrieb Andy <[email protected] <javascript:>>: > > >> Ah, okay. I think I understand what I was missing initially. I've had > >> another go at this and it seems to work as required, even on MySQL. > Not > >> sure how this all works with SQLAlchemy but I would expect it to be > fine > >> with it. > >> > >> insert into favourites (thing_id, group_id) values (2, 2) > >> Error Code: 1062. Duplicate entry '2' for key 'PRIMARY' 0.012 > sec > >> > >> insert into favourites (thing_id, group_id) values (1, 3) > >> Error Code: 1452. Cannot add or update a child row: a foreign key > >> constraint fails ("favourites"."favourites", CONSTRAINT "checker" > >> FOREIGN > >> > >> KEY ("thing_id", "group_id") REFERENCES "groups_things" ("thing_id", > >> "group_id")) 0.007 sec > >> > > > > It's not, at least with automatically configured relations, hence this > > thread. > > What do you mean with automatically configured relations? Using SQLa to > define the schema? I always manage the schema directly so I don't know so > > much about that. For me, the important thing is that SQLa can work with > the schema with the least number of contortions and I don't see any > required here. >
It's the original issue. The relation (that I want the ORM to see) isn't what's literally set in the schema by foreign keys, and the primaryjoin/foreign_keys ORM magic for this IMO sucks. Something like "onetomany" and "manytoone" in the mapper config would solve the problem nicely. > > >> > Also, SERIAL? You must be using a real database engine. > >> > >> Well, er, yes. When it comes to modelling that's where you should > start. > >> And Oracle is making progress with MySQL now that InnoDB with separate > >> files pro table and 5.6 even seems to have some kind of vacuuming > >> built-in. > >> > > > > I dunno. This may be the end of my (nonexistent) web developer career, > > > but > > I think I will never again recommend using mysql for any purpose > > whatsoever > > (except perhaps compatibility). I've learned my lesson. Next time I'll > > use PostgreSQL. > > Well, yes, I'd always recommend Postgres over MySQL but I don't see what > the choice of backend has to do with this problem, except how well > reflection works with Postgres. From a developer's perspective MySQL's > biggest problem, apart from MyASM, is that its behaviour can be > unpredictable. > The MySQL vs PostgreSQL holy war is completely irrelevant to this issue :) -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
