I've followed discussions here and on d.o about removing unneeded revisions tables.
How would I completely prevent any data from being written to the node_revision and field_revision_* tables?
6
4
Field SQL norevisions actually solves exactly that problem by
Field SQL norevisions provides a field storage backend using SQL that does not create a revision table for each field.
I haven't tried it, but anything written by Alex Pott can probably be expected to work properly.
I assume however that this also goes for all entites as it changes the storage backend.
Without a new storage engine, the below is the original, less useful, answer:
The revision tables must be available, and they must contain data. Unfortunately, you just cannot get rid of them without completely breaking Field API, the reason being that the revision, contrary to their name, is the data storage.
Perhaps it's possible, with more database wizardry than I know, that you can set the regular field_data_* tables to be mirrors of each revision table. That might work.
Other than that, I can't think of any solution that would do this.
Edit: While I don't know if this will have, "interesting", side effects, I asked the wizards if this was at all doable. Can I have one table be an alias or symlink to another?.
Edit 2: Actually, it seems like much wizardry isn't needed at all. One could try replacing the field_data_* tables with a View that replicates the corresponding revision tables. Again, I haven't tried this, and my understanding of the interals of field api are a bit lacking, but it certainly could work.
Edit 3: (Yes, this is getting silly), someone pointed out that the above will cause the same data to be written twice, now to the same table. So it probably wont work anyway.
answered May 25 '12 at 18:25
-
my understanding is that the node data is copied to the revision table (duplicated) and same for the field_data. If you could prevent the data from being inserted into those tables nothing should happen as long as you are not using the revision feature. Or am I missing something? – uwe May 25 '12 at 20:04
-
2The problem is that it's the other way around. The revision tables are by core considered the canonical source of information. Field data, despite their name, are just denormalization. – Letharion May 25 '12 at 20:55
-
that's interesting, thanks! Still a huge waste of resources for probably 90% of sites that don't use revisions. – uwe May 26 '12 at 20:39
-
Not true anymore! Field SQL norevisions claims to solve that problem. I haven't tried it but the code looks very promising! @MotoTribe found this one I can't take the credit ;) – Clive♦ Jan 24 '13 at 18:10
-
Interesting that the module appears to have been written already when we had the initial discussion. @Clive, you should post that as a new answer. :) – Letharion Jan 24 '13 at 21:50
