On Thu, Dec 31, 2009 at 12:25 PM, CB <cbw...@gmail.com> wrote: >> In short, you can't (or shouldn't). >> >> What you're asking the database to do is keep a foreign key value that >> is not valid on the database on which it is stored. > > Yes, this is true. > > >> The multi-db branch had checks for this sort of referential integrity >> until just before the merge; however, these checks were relaxed just >> prior to commit in order to allow for multi-db to support master-slave >> partitioning - in these situations, a model will appear to be on a >> different database alias, but won't be a referential integrity failure >> since it is actually the same database. > > Yeah, i watched these checks go up and then drop out. > >> We may also need to look at ways of storing >> cross-database foreign keys to accommodate the sort of use case that >> you describe. > > What about creating a new set of ForeignKey fields that don't actually > do any real foreign key checking? Maybe CrossDBForeignKey, or > RelaxedKey?
I suspect something like this will ultimately form part of the solution. There are potentially two types of 'relaxed' FK required - * A FK when you know that the source data always comes from another specific database (e.g. User objects are only on the 'auth' database) * A FK that could point to one of many databases (e.g., Users are spread across multiple databases based on some sharding strategy). Analogous fields will need to exist for M2M fields. > I understand if this is off the timetable for 1.2 (as I can see the > dev group is getting ready for freeze, etc) but if I wanted to develop > this route, do you have any pointers? Might I be able to simply > subclass ForeignKey (or one of it's bases, etc), and more or less lie > about the constraint being fulfilled, tell the DB that this is just an > int (like IntegerField), and then convince the Query internals to ask > for my data seperately (making it not eligible for select_related, for > example)? I haven't tried this myself, but subclassing ForeignKey certainly seems like a reasonable starting point. One complication will be the SQL that is generated; essentially, you need the field to be a FK, but *not* generate field constraints. It *might* be easier to start by subclassing IntegerField, and then introduce an FK-compatible API that accommodates the remote data source. > Either way, i'm going to look into this use case myself and try to > make it work (in a hopefully not /too/ hacky way) . If you or anyone > else has any pointers, please let me know. At this point, you have pretty much all the pointers that I personally have to offer. I'm certainly interested to hear from anyone else on this topic. If you manage to get this working, it would be helpful to hear about any problems you experience. If we're going to put these user-facing features into trunk in the 1.3 timeframe, it would be helpful to have pointers/hints/experiences from people who have actually used multi-db in real-world situations. To that end - if you find that there is a need to modify the core in some subtle way (for example, adding a flag/option to disable select_related), feel free to suggest it. Depending on the proposal, it might not even be out-of-bounds for 1.2. If you can make the case for a generally transparent change to API that will make multi-db practical for a particular use case, it might be covered as a bug fix, and therefore be an acceptable checkin right up until the RC freeze. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
