On 4/20/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > In your descriptions below, you remove the ability for a developer to > use manual primary keys, by the sound of it, since one of your special > fields wants to be a single-column primary key. That's not invisible.
Does Django currently allow use of composite primary keys? If so, I wasn't aware. Either way, the only restriction I would want to put on the keying of the tables is that they not use one of the reserved column names (e.g. "record_is_deleted"). I wouldn't go as far as to say "significantly heavier" without a lot of > profiling under operational loads. Using sensible table indexing, > including functional indexes on databases that have them, should make > that query perform reasonably well for many cases (gut feel based on a > bit of experience with large databases). Fair enough. It definitely makes the queries more complex, since they must always include statements to select the current, non-deleted record. But that doesn't mean the performance would be unacceptable. A real drawback of this method that you don't mention is that adding > audit support requires changing the database table. So you can't add it > to standard (shipped with Django) or third-party modules easily. Yes, I would prefer my solution be drop-in compatible with both standard Django and typical third-party modules. Which does argue against modifying the model tables. > 2. The audit table, as described above, is written seperately > > from the working table used for reads. It would be most > > You still have to change the main table for the model, though, right? > Otherwise you won't be able to have more than one tuple of data for each > model (due to constraint violations). This was a problem that existed in > the design of the FullHistory work as well: how to store arbitrary bits > of changed information without having to alter existing tables. No, I will not need to change the main table for the model. But as you point out, the audit table's schema cannot simply be main table + record-keeping columns. Instead, its schema must be: main table with modified contraints + record-keeping columns. If you could find a way that all the audit-related information was in a > separate table, I would be tempted to implement it similar to > ContentTypes -- as a table that is related to the model(s) it governs > (maybe there is a shadow audit table for each real model table, but > that's a bit uncool from a database design perspective). The extra table > join won't really hurt you with today's databases and proper indexing. Keeping a shadow table for each audit table is looking like the best solution to me right now. Granted it does add a little clutter to the table namespace -- but shadow tables will be created only for models that explictly ask for them. Is it worthwhile to make it possible to store the audit shadow tables in a separate db? I suspect you will be able to do most of it as a third-party app without > needing to hack on core. Some monkey patching -- a term I hate because > it suggests it is wrong somehow, but I'll stick with the common phrase > -- of the QuerySet class might be necessary (replacing QuerySet with a > version that understands how to get the "real" row for a model). You > might be able to get away with subclassing QuerySet in a lot of cases, > but I'm not sure that will give you everything. If I am only interested in writing shadow tables to keep history, don't think I would need to touch QuerySet. Instead, just define some pre_save and pre_delete callbacks for the dispatcher. (And maybe post_save and post_delete, to verify that the save/delete had been successful?) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
