Переупорядочение записей в модели с помощью перетаскивания
Размер структуры больше, чем сумма ее частей из-за того, что называется упаковкой. У конкретного процессора есть предпочтительный размер данных, с которым он работает. Большинство современных процессоров предпочитают размер, если 32 бит (4 байта). Доступ к памяти, когда данные находятся на этом типе границы, более эффективен, чем те, которые охватывают эту границу размера.
Например. Рассмотрим простую структуру:
struct myStruct
{
int a;
char b;
int c;
} data;
Если машина является 32-разрядной машиной, а данные выровнены по 32-битной границе, мы видим немедленную проблему (при отсутствии выравнивания структуры). В этом примере предположим, что данные структуры начинаются с адреса 1024 (0x400 - обратите внимание, что младшие 2 бита равны нулю, поэтому данные выравниваются с 32-разрядной границей). Доступ к data.a будет работать нормально, потому что он начинается на границе - 0x400. Доступ к data.b также будет работать нормально, поскольку он находится по адресу 0x404 - еще одна 32-разрядная граница. Но неуравновешенная структура поставит data.c по адресу 0x405. 4 байта данных.c находятся в 0x405, 0x406, 0x407, 0x408. На 32-битной машине система считывала data.c в течение одного цикла памяти, но получала бы только 3 из 4 байтов (четвертый байт находится на следующей границе). Таким образом, системе потребуется второй доступ к памяти для получения 4-го байта,
Теперь, если вместо того, чтобы поместить data.c по адресу 0x405, компилятор заполнил структуру на 3 байта и поместил данные. c по адресу 0x408, тогда системе потребуется всего 1 цикл, чтобы прочитать данные, сократив время доступа к этому элементу данных на 50%. Заполняет эффективность памяти для эффективности обработки. Учитывая, что компьютеры могут иметь огромные объемы памяти (много гигабайт), компиляторы считают, что своп (скорость над размером) является разумным.
К сожалению, эта проблема становится убийцей при попытке отправить структуры по сети или даже записать двоичные данные в двоичный файл. Прокладка, вставленная между элементами структуры или класса, может нарушить данные, отправленные в файл или сеть. Чтобы написать переносимый код (тот, который будет использоваться для нескольких разных компиляторов), вам, вероятно, придется обращаться к каждому элементу структуры отдельно, чтобы обеспечить надлежащую «упаковку».
С другой стороны, разные компиляторы имеют разные возможности для управления упаковкой структуры данных. Например, в Visual C / C ++ компилятор поддерживает команду #pragma pack. Это позволит вам настроить упаковку и выравнивание данных.
Например:
#pragma pack 1
struct MyStruct
{
int a;
char b;
int c;
short d;
} myData;
I = sizeof(myData);
Теперь я должен иметь длину 11. Без прагмы я мог бы быть чем угодно из 11 до 14 (а для некоторых систем - до 32), в зависимости от стандартной упаковки компилятора.
3 ответа
Чтобы рабочий код сделал это, проверьте отрывок 1053 по djangosnippets.org.
Примечание по "Было бы лучше, если бы я не должен был добавлять дополнительные поля к модели, но если я действительно имею, я могу".
Извините, но порядок информации в базе данных определяется самой информацией: всегда необходимо добавлять столбец для упорядочивания. Нет действительно никакого выбора относительно этого.
Далее, для получения вещей в этом порядке необходимо будет конкретно добавить .order_by(x) к Вашим запросам или добавляют ordering к Вашей модели.
class InOrder( models.Model ):
position = models.IntegerField()
data = models.TextField()
class Meta:
ordering = [ 'position' ]
Без дополнительного поля упорядочивание не может произойти. Это - одно из правил реляционных баз данных.
В образцовом классе необходимо было бы, вероятно, добавить поле "порядка", для поддержания определенного порядка (например, объект с порядком = 10 является последним, и порядок = 1 является первым). Затем можно добавить код JS в администраторе change_list шаблон (см. это) поддержать drag&drop функцию. Наконец упорядочивание изменения в Meta модели к чему-то как ['порядок'].