Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Есть два класса с отношением один-много. Создаем объект "родитель", связываем его с "детьми" в определенном порядке. После сохранения, закрытия и поднятия объекта "родитель" порядок следования элементов "дети" меняется на обратный. Кто сталкивался с такой проблемой? Что делать, если порядок следования важен - т.е. 1-й элемент должен быть всегда первым, а последний - последним. Всякие извращения с переварачиванием массива не предлагать! Если надо, могу кинуть пример... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 06:33 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Так при создании экземпляров id формируется с нарастанием. Как ваши "дети" могут сортирануться по "следованию" в обратном порядке? Как вы "поднимаете" "родителя"? ---------- Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 08:21 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Чтобы стало понятней вот тестовые классы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Далее выполняем такой примерчик: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 09:27 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Я не использую такой тип связи Родитель-Дети... Отдаю предпочтение "чистому" Один-ко-многим... При этом применяю немного другую конструкцию при создании Код: plaintext 1. 2. 3. 4. 5. 6. 7. Т.о. и связь есть... И пресловутое следование не нарушено... Как вариант может вам после каждого Код: plaintext Делать Код: plaintext Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 10:31 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Вот даже пример из ОбжектКвикСтарта... авторСоздайте в памяти двух пациентов и доктора: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Теперь Вы можете получать информацию о связанных объектах с обеих сторон отношения: Код: plaintext 1. 2. 3. 4. 5. ---------- Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 10:42 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
1. Какой тип отношений использовать (parent-child, one-many) нет абсолютно ни какой разницы. 2. До зарытия объектов и поднятия с базы заново все работает нормально, у элементов правильный порядок. 3. Объекты предварительно сохранять в базу не надо. Надо сначала всё заполнить, а потом, в нужный момент, если это требуется, сохранить. Манипуляции с последующим удалением ненужных объектов не приветствуются. 4. При последующих сохранениях порядок элементов не меняется. Проблема возникает после первого сохранения объекта. Если после первого примера выполнить этот пример, то получится интересная ситуация: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ИМХО - это неправильное поведение. Почему это происходит именно при первом сохранении и как с этим бороться - ума не приложу. Как вариант - написать своё подобие отношения с простыми свойствами типа list или array... Пока только такие мысли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 17:05 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Ну во первых хочеться сказать что при работе с детишками через "Абстрактный базовый" набор GetAt Next Prev и т.д. - индекс равен непонятно чему Во вторых Команда Insert - можно трактовать именно как вставку - то есть при вставке все текущие элементы сдвигаются вниз. Проверить это можно во первых - выведя w parent.childrens.GetAt(1).name ПЕРЕД сохранением парента - есть мнение что там _уже_ будет три Во вторых просмотрев ID-ники детишек, если не переопределяли свой ID то там должно быть поле childsub. Если 3-й ребенок сохраняеться первым - то вполне можеть быть что при последующем GetAt(1) вы получите именно его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 20:13 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Socratdv3. Объекты предварительно сохранять в базу не надо. Надо сначала всё заполнить, а потом, в нужный момент, если это требуется, сохранить. А вот это уже какое-тоноу-хау... Т.е. вы набираете, набираете эелементы "как буд-то бы в БД"... А потом можете и не записывать? Тогда зачем весь сыр-бор? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2008, 20:38 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
PtnНу во первых хочеться сказать что при работе с детишками через "Абстрактный базовый" набор GetAt Next Prev и т.д. - индекс равен непонятно чему Малость не понял этой реплики... С чего бы это индекс был равен непонятно чему? Все предельно ясно - индексы в списке от 1 до кол-ва элементов. PtnВо вторых Команда Insert - можно трактовать именно как вставку - то есть при вставке все текущие элементы сдвигаются вниз. Проверить это можно во первых - выведя w parent.childrens.GetAt(1).name Метод Insert добавлят элемент в конец списка без какого либо сдвига - эквивалентен ..childrens.SetAt(child,..childrens.Count()+1). Сам по себе метод Insert отрабатывает нормально, элементы ВСЕГДА добавляются в конец. w parent.childrens.GetAt(1).name выдаст результат "1" PtnПЕРЕД сохранением парента - есть мнение что там _уже_ будет три Перед сохранением родителя, как и после, всё работает нормально - порядок не меняется. Проблема возникает при ПЕРВОМ сохранении родителя (когда у него нет id), после его закрытия и поднятия с базы (когда отрабатывает метод Load у RelationshipObject). Проблема в том, что при ПЕРВОМ сохранении дети сохраняются в обратном порядке, в последующем все нормально. PtnЕсли 3-й ребенок сохраняеться первым - то вполне можеть быть что при последующем GetAt(1) вы получите именно его. Вот именно так и происходит. НО только при первом сохранении. Как это разрулить - ума не приложу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2008, 10:51 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
krvsa Socratdv3. Объекты предварительно сохранять в базу не надо. Надо сначала всё заполнить, а потом, в нужный момент, если это требуется, сохранить. А вот это уже какое-тоноу-хау... Т.е. вы набираете, набираете эелементы "как буд-то бы в БД"... А потом можете и не записывать? Тогда зачем весь сыр-бор? А вы считаете, что надо сначала записывать объект в базу а потом заполнять данными? Вот это уж точно какое-то ноу-хау... Сыр-бор в том, что сохранять надо, когда захочет пользователь. Если пользователь скажет, что сохранять не надо, то объекты просто закрываются, не внося изменения в базу. Как пример можно привести отношение документ-строки документа. Создается документ, добавляются строки, вносятся данные и когда пользователь жмет сохранить, то сохраняем родитель (документ). Если пользователь жмет отмену, то закрываем документ без сохранения. Помоему, это более чем нормальная ситуация... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2008, 11:00 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
Т.к. список детей в родителе заполняется при поднятии с базы выборкой сохраненных элементов, то в первой позиции всегда будет тот элемент, который сохранен раньше остальных. Позиция в списке ни где не учитывается и сделать так, чтобы порядок элементов был постоянным не представляется возможным. Вопрос можно снимать с обсуждения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2008, 11:41 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
SocratdvА вы считаете, что надо сначала записывать объект в базу а потом заполнять данными? Я-то считаю что "если пользователь не хочет записвать данные" вообще не делать какие-то манипуляции с данными... А у вас получается то, что у вас получается... Измените ваш подход к делу и будет вам счастие... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2008, 11:49 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
SocratdvВот именно так и происходит. НО только при первом сохранении. Как это разрулить - ума не приложу... Элементарно - сохранять каждого ребенка сразу - или использовать SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2008, 12:33 |
|
||
|
Обратный порядок элементов в Relationship
|
|||
|---|---|---|---|
|
#18+
>>Малость не понял этой реплики... С чего бы это индекс был равен непонятно чему? Все предельно ясно - индексы в списке от 1 до кол-ва элементов. Он имеет ясное значение при использовании списков или массивов - там индекс имеет непосредственное физическое значение... В случае парент-чилд - индексом вообще то выступает ID чилда - который к этим циферками 1 2 3 4 не имеет ну никакого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2008, 12:37 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=35498714&tid=1558780]: |
0ms |
get settings: |
11ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
60ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 390ms |

| 0 / 0 |
