Вверх ↑
Этот топик читают: Гость
Администрация
Ответов: 15273
Рейтинг: 1501
#151: 2007-09-11 08:38:44 ЛС | профиль | цитата
Alexbootch, ну нельзя использовать rowid в качестве идентификатора записи. Зачем копать себе яму на будущее вместо того, чтобы подумать заранее?
карма: 23
0
Разработчик
Ответов: 25465
Рейтинг: 2071
#152: 2007-09-11 20:11:58 ЛС | профиль | цитата
Dilma писал(а):
ну нельзя использовать rowid в качестве идентификатора записи

Dilma, вот осталось такой вывод подтвердить примером, тем как можно. Благо, Alexbootch совершенно правильно понял задачу и очень подробно ее описал.
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#153: 2007-09-11 21:05:38 ЛС | профиль | цитата
nesco, может быть мы по разному понимаем чем постановка задачи отличается от её реализации?

Dilma писал(а):
основываясь на предыдущем опыте этого же поста полагаю имеет смысл излагать задачу полностью.


Dilma писал(а):
(следующий на единицу больше предыдущего) - есть занятие бессмысленное(не оправданное). Точнее можно сказать при наличие примера.

карма: 23
0
Разработчик
Ответов: 25465
Рейтинг: 2071
#154: 2007-09-11 22:58:20 ЛС | профиль | цитата
Dilma, не все можно упихать в десяток компонентов, а выкладывать прогу из 1500 тысяч элементов, просто бессмысленно. Я еще подумаю над собственной реализацией, удалось же самому реализовать некоторые пояснения сего топика. А смысл задачи очень простой -- есть N каналов с набором параметров (строки таблицы), их надо последовательно загрузить в динамические мультики, актвировав в последних определенные части схемы, но для редакции они должны в такой же последовательности выводиться на экран. Получается так -- если в экранной таблице это 2-я строка, то в дальнейшем за этот канал будет отвечать именно 2-й динамический мультик. Мультики имеют последовательную нумерацию на единицу больше предыдущего, вот откуда и взялось это
Dilma писал(а):
(следующий на единицу больше предыдущего) - есть занятие бессмысленное(не оправданное).

карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#155: 2007-09-11 23:16:30 ЛС | профиль | цитата
nesco, вот с этого и следовало начинать. Собственно единственно правильное тут решение, это паралленьное хранение ##handle где-нибудь в массиве, благодяря которому всегда будет можно по индексу получить Handle мультика, затем выполнить ##HSelect и далее уже через primary key(сохраненный в каждом мультике для своей записи) обращаться к базе. Надежное и достаточно простое решение.
карма: 23
0
Разработчик
Ответов: 25465
Рейтинг: 2071
#156: 2007-09-11 23:29:31 ЛС | профиль | цитата
Dilma, оригинально. Но как-либо упрощенно это нельзя на пвльцах показать? Я не понял момента с ##handle, они разве не меняются при каждом запуске и создании N количества мультиков?
Dilma писал(а):
сохраненный в каждом мультике для своей записи
и как это осуществить тоже не понятно.
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#157: 2007-09-12 00:51:19 ЛС | профиль | цитата
насколько я понял задачу мультик создается один раз для каждой записи из базы. ак вот ему при создание нужно передавать в качестве параметра(например в потоке точки ##add) primary key из базы и сохранять скажем в memory.

##handle при каждом запуске меняются, но тут это не важно. Важно то, что при таком решение нет привязки к конкретному индексу.

code_1915.txt

в примере: элемент For это цикл получения записей из таблицы, элемент Random это получение primary key для записи. При выборе пункта списка получаем по индексу уникальный ID записи и далее делаем свои дела. Очевидно, что при синхронном удаление строки из listbox, MultiElementEx и массива ничего пересчитывать нигде не нужно и при этом схема будет совершенно коректно работать.
карма: 23
0
файлы: 1code_1915.txt [1.2KB] [148]
Разработчик
Ответов: 25465
Рейтинг: 2071
#158: 2007-09-12 02:53:39 ЛС | профиль | цитата
Dilma, я рассмотрел твою схему, действительно оригинальное решение, но у нее есть один недостаток -- быстродействие. Я отказался от выполнения каких-либо циклических запросов внутри мультика и по точке ##add уже передаю считанные основные параметры, сохраняя их в MT_MultiMem внутри каждого мультика для каждого канала (остался у меня, правда, один запрос в мультиках, но делается он только по ##add). Каналы считываются из базы все, в той последовательности, как они там идут, параллельно сортируясь по параметру Status, означающем включение/выключение канала (вот запрос, выполняющий оисанные действия -- SELECT idx, Port, Baud, Color, Lines FROM Channels WHERE Status = 1;. В данном случае ##add будет столько, сколько будет выборок из базы. Для определения их возможного количества выполняется перед предыдущем запросом запрос -- SELECT COUNT (Status) FROM Channels WHERE Status = 1;. Сравнивая количество созданных мультиков по ##count с полученным количеством выборок, я определяю конец цикла создания и начало перехода на цикл опроса. Вот схемка, поясняющая этот метод code_1917.txt), и по-этому мультиков тоже получается заранее неопределенное количество, но в таком случае в память не грузятся "мертвые души", и никакой привязки к Id. Сложность возникла как раз не в организации мультиков, это оказалось для меня самым простым, а именно в физической сортировки строк в самой базе, особенно после удаления, когда индексы теряют заданную последовательность, и она не соответствует последовательности в экранной таблице, ну например: после удалени и перечитывания базы в экранной таблице строки нумеруюются как 0,1,2,3,4,5, а в базе -- 1,2,3,5,6,7. И как дальше работать -- выбираешь 0-ю строку -- ей соответствует 0+1 Id базы, а выбираешь 4-ю строку -- ей уже соответствует 4+2 Id базы, а вот rowid, если его упорядочить (по Vacuum, как рекомендут Alexbotch) как раз и будет 4+1. Какой выход ты можешь посоветовать в данной ситуации, чтобы уйти от rowid.

карма: 19

0
файлы: 1code_1917.txt [1.3KB] [144]
Администрация
Ответов: 15273
Рейтинг: 1501
#159: 2007-09-12 10:24:42 ЛС | профиль | цитата
nesco, на счет быстродействия не понял. По поводу индексов тоже - предложенное решение разве не является решением? Еще раз суть идеи: нельзя запросы от программы к базе реализовывать на каких бы то ни было номерах. Даже больше - нельзя идентифицировать запрос по полю, от изменения которого мы не застрахованы. В приведенном примере как раз и показано, что правильнее и надежнее делать такую ассоциацию в самой программе(Index в листбоксе -> ##Handle контейнера), где мы имеем полный контроль.
карма: 23
0
Разработчик
Ответов: 25465
Рейтинг: 2071
#160: 2007-09-12 11:47:46 ЛС | профиль | цитата
Dilma, похоже, мы просто не понимаем друг друга. Вот первое
Dilma писал(а):
Даже больше - нельзя идентифицировать запрос по полю, от изменения которого мы не застрахованы
Непонятно к чему это относится. В моей схеме запросы к базе и загон параметров в мультики происходит только один раз -- при создании мультика, все, дальше никаких изменений параметров в мультике не происходит, за исключением связи с внешними данными, никак не связанными с загружаемой базой. Ну изменится основной параметр сортировки до момента загрузки, ну и что -- мультик будет, либо создан, либо нет. Опрос мультиков происходит обычным счетчиком и тоже не связан с базой, только при создании мультиков.
Dilma писал(а):
правильнее и надежнее делать такую ассоциацию в самой программе(Index в листбоксе -> ##Handle контейнера), где мы имеем полный контроль
А разве нельзя использовать обычный ##select с индексом мультика, который выдается счетчиком, параметры то уже внутри?
Dilma писал(а):
Еще раз суть идеи: нельзя запросы от программы к базе реализовывать на каких бы то ни было номерах

Тоже не могу понять, почему нельзя использовать какие-либо последовательности индексов для вывода на экран и перестановки строк. Везде в примерах применяют индексы и последовательные значения, тут же получается совсем наооборот. Хорошо, а если больше привязаться не к чему, только к индексу, все остальные парметры разные, и что теперь делать?
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#161: 2007-09-12 12:23:16 ЛС | профиль | цитата
nesco, к сожалению сложно понять задачу, часть постановки которой основана на выдержках из конкретного примера конкретной схемы.

nesco писал(а):
Везде в примерах применяют индексы и последовательные значения, тут же получается совсем наооборот

в каких примерах?

nesco писал(а):
Хорошо, а если больше привязаться не к чему, только к индексу, все остальные парметры разные, и что теперь делать?

привязываться всегда и везде надо к уникальному параметру, одназначно характеризующему объек/запись на все время его жизни.

Конкретный вопрос: что на этот раз не удается сделать, если
- правильная перестановка записей была описана
- правильная идентификация записей была приведена
- корректное удаление без пересчета было дано
- переход от индекса записи в элементе отображения к уникальному ключу записи был дан

карма: 23
0
Разработчик
Ответов: 25465
Рейтинг: 2071
#162: 2007-09-12 13:54:20 ЛС | профиль | цитата
Dilma писал(а):
- корректное удаление без пересчета было дано

Кем дано? Alexbotch применяет rowid, а мы говорили об его анулировании. У меня все и так неплохо работает, но разговор был о несостоятельности методов применения абсолютных индексов строк, вот я и решил отойти от применения rowid и столкнулся с тем, что привязаться то не к чему, особенно, после удаления строки, когда получаются индексные разрывы.
Мне нужно соответствие индексов табличного экранного вывода и физического расположения строк, все -- остальное уже сделано. Те, если я выбираю строку экранной таблицы с индексом 3, то она должна быть в базе с индексом 4 и никакой другой.
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#163: 2007-09-12 14:16:29 ЛС | профиль | цитата
Dilma писал(а):
предложенное решение разве не является решением?


[size=-2]------ Добавлено в 14:16
nesco писал(а):
Кем дано?

Dilma писал(а):
Очевидно, что при синхронном удаление строки из listbox, MultiElementEx и массива ничего пересчитывать нигде не нужно и при этом схема будет совершенно коректно работать.

карма: 23
0
Разработчик
Ответов: 25465
Рейтинг: 2071
#164: 2007-09-12 14:36:04 ЛС | профиль | цитата
Dilma, ну если в этом случае, то я не спорю, да и не собираюсь спорить. Но мне и не обязателен был случай, когда параметры нужно считывать в каждой текущей схеме. У меня похожий вариант был в начале, и я добился результата, когда в память не грузятся "мертвые души" и также не используются индексы. Меня больше волнует режим редактирования, чем режим создания, опроса и удаления мультиков. Ну например: как ты делаешь перемещение иконок по палитре, они же могут ездить вверх и вниз, это сохраняется в файле базы или в файле конфигурации?
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#165: 2007-09-12 14:58:24 ЛС | профиль | цитата
nesco писал(а):
как ты делаешь перемещение иконок по палитре

точно так же, ка кописывал tsdima в этом топике на примере поля MySort. В базе данных hiasm оно завыется несколько иначе - pos.

PS: вот если бы в elements.db запросы к базе проходили через идентификацию по индексу(т.е. номеру элемента в палитре) то даже представить сложно, в какую бы кашу превратилась таблица при одновременном перемещение/удаление/вставки элементов палитры из двух экземпляров среды. Скажем алгоритм с использование VACUM при удаление одного и тоже эелемента из двух копий среды привел бы на самом деле к удалению двух элементов, о чем юзер бы узнал только при следующем запуске...
карма: 23
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)