Здравствуйте
Попался мне проект с бд на типизированных файлах(их тьма). Хотел сделать админку для них, но структуру хотелось бы вынести, хоть в JSON или в INI, или в какой-нибудь sqlite и т д.
Чтобы я мог зайти в файлик(простой) прописать структуру без компиляции. И у меня появился бы это файл в админке и я бы его мог редактировать(редактировать типизированый файл) (можно после перезагрузки админки).
Насколько я понимаю существуют несколько решений:
1. Не думать и просто прописать рекорды в код(исходник), добавив к ним ассоциации с конкретными файлами.
2. Насколько я понимаю, я могу эмулировать(наверно) рекорд и можно читать побайтно типизированный файл и получать нормальные данные (я же знаю длину строк и т. д.), писать в файл придётся так-же. При этом я могу получать структуру уже не из кода.
3. Я посмотрел PascalScript, он не подойдёт для такого (насколько я понял), но можно попробовать использовать какой-нибудь интерпретатор в связке (я предполагаю, что смогу объявить тип данных во время выполнения и буду читать и писать уже оттуда, вместе с передачей данных). Здесь тоже структура не из кода.
4. dll - то же самое что и первый пункт.
Я не могу принять решение, в какую сторону мне двигаться. Возможно я не вижу какого-то очевидного решения...
Пожалуйста, подскажите мне, в какую сторону двигаться, я буду рад любой идее, в том числе альтернативной.
p/s. Я повторюсь, постоянная компиляция(каждый день), на данном проекте не лучшее решение. Один я, к примеру, справлюсь с работой за пол года. А если надо просто будет добавлять текст в файлы то 20 человек, справятся за короткий промежуток времени.
Как создать динамический Record
Модератор: Модераторы
я за 2 вариант - вполне норм, но посложнее в реализации.
Сам исползовал подобное, но за ненадобностью чисто рантаймных определений структур данных ушел на compileтаймные.
Был написан парсер паскалеподдодного языка и определенные в рантайме рекорды и обжекты вполне жили внутри программы. но были трудности с выравниванием данных (либо везде packed, либо на каждой платформе свои правила)
Сам исползовал подобное, но за ненадобностью чисто рантаймных определений структур данных ушел на compileтаймные.
Был написан парсер паскалеподдодного языка и определенные в рантайме рекорды и обжекты вполне жили внутри программы. но были трудности с выравниванием данных (либо везде packed, либо на каждой платформе свои правила)
2 вариант видится единственно разумным в случае если их (вариантов структур) очень много и тем более если в перспективе еще подвалят
да и потом в логи там писать рекорды желательно то се, т.е. реализация мапинга поле = значение и так нужна для отладки будет
и на скорость почти не влияет
да и потом в логи там писать рекорды желательно то се, т.е. реализация мапинга поле = значение и так нужна для отладки будет
и на скорость почти не влияет
to sts zab
Спасибо большое за ответы, я просто не встречался с таким. Посоветовался с коллегой Си/СИ++, он тоже за 2
to zab
крутая штука.
to All
есть такая штука
Идентификация типа во время исполнения (RTTI)
буду смотреть насколько она у нас есть
Спасибо большое за ответы, я просто не встречался с таким. Посоветовался с коллегой Си/СИ++, он тоже за 2
to zab
Был написан парсер паскалеподдодного языка и определенные в рантайме рекорды и обжекты вполне жили внутри программы. но были трудности с выравниванием данных (либо везде packed, либо на каждой платформе свои правила)
крутая штука.
to All
есть такая штука
Идентификация типа во время исполнения (RTTI)
буду смотреть насколько она у нас есть
>>Идентификация типа во время исполнения (RTTI)
Она есть, но не в том количестве как в делфи. Недоделано
Для рекордов емнип можно получить смещение полей и тип. имя нельзя.
В любом случае RTTI работает только с типами данных определенными на момент компиляции
Она есть, но не в том количестве как в делфи. Недоделано
Для рекордов емнип можно получить смещение полей и тип. имя нельзя.
В любом случае RTTI работает только с типами данных определенными на момент компиляции
>>видимо нельзя....
все можно. только на ртти пока сильно расчитывать не приходится. темболее в случае
>>прописать структуру без компиляции.прописать структуру без компиляции.
ртти не работает, оно только для структур данных описаных в компилируемых исходниках
https://bugs.freepascal.org/view.php?id=38964
надеюсь скоро родят))
все можно. только на ртти пока сильно расчитывать не приходится. темболее в случае
>>прописать структуру без компиляции.прописать структуру без компиляции.
ртти не работает, оно только для структур данных описаных в компилируемых исходниках
https://bugs.freepascal.org/view.php?id=38964
надеюсь скоро родят))
Есть еще одни "отверточный" но довольно простой путь решения подобных проблем :
Закинуть все данные "динамического рекорда" в форматированную строку .
Да приходится писать хитрые методы доступа к конкретными полям(особенно на запись ) зато ни каких проблем созданием списков и дополнительным распределением памяти.
Сейчас в моей техно-демке есть два разных метода создания "древовидных динамических структур" одна реализована с помощью строк, а другая с помощью классов и обычных рекордов .
Казалось бы "отверточная" на строках должна быть куда сложнее но оказывается что строчная успешно работает, а "классическая" (особенно к моему удивлению та что реализована у меня с помощь классов (вроде как призванных все облегчить ) просто жуть как меня замучила!
Зы
Пример "текстовой древовидности" и "полиморфизма" сохраняемых в строке данных
Четко видно общую часть и "ответвление" под конкретный тип. (Причем это не с сформированный для записи формат, а именно "базовая структура" )
Закинуть все данные "динамического рекорда" в форматированную строку .
Да приходится писать хитрые методы доступа к конкретными полям(особенно на запись ) зато ни каких проблем созданием списков и дополнительным распределением памяти.
Сейчас в моей техно-демке есть два разных метода создания "древовидных динамических структур" одна реализована с помощью строк, а другая с помощью классов и обычных рекордов .
Казалось бы "отверточная" на строках должна быть куда сложнее но оказывается что строчная успешно работает, а "классическая" (особенно к моему удивлению та что реализована у меня с помощь классов (вроде как призванных все облегчить ) просто жуть как меня замучила!
Зы
Пример "текстовой древовидности" и "полиморфизма" сохраняемых в строке данных
Код: Выделить всё
ObJ [Obj01] T(4 Куб) TP(1,1,0) SC(1,1,1) RT(0,0,0) TR[0,0] * CubColor[65535]
ObJ [Obj-1] T(1 Модель ASC) TP(5,0,-0.2) SC(1,1,1) RT(-90,0,0) TR[1,21] * NF[123.ASC] Color[12632256] ID[138468]
ObJ [Obj-1] T(3 Модель 3DS) TP(-2,0,0) SC(0.01,0.01,0.01) RT(90,0,0) TR[0,60] * NF[OLDCITY3.3DS] ID[34844416]
ObJ [Obj-1] T(6 Линия) TP(0,0,0) SC(1,1,1) RT(0,0,0) TR[0,0] * LData[(-0.5,0,0)-(0.5,0,0)-(0.5,-0.5,0)-(-1,-0.5,0)-(-1,0.5,0)-(1,0.5,0)-(1,-1,0)-(-1.5,-1,0)-(-1.5,1,0)-(1.5,1,0)-(1.5,-1.5,0)-(-1.5,-1.5,0)] LW[3] LK[0] LP[0] LColor[65280]
Четко видно общую часть и "ответвление" под конкретный тип. (Причем это не с сформированный для записи формат, а именно "базовая структура" )
to Alex2013
Спасибо Вам за ответ. Если по поводу древовидных динамических структур... Я могу сказать что прекрасно вас понимаю, даже с JSON работать тяжеловато, но меня могут и забить камнями =)))
Скажем так, по сравнению с JavaScript работать с динамикой не легко. Этому есть внятные и понятные объяснения, но я всё равно могу помечтать. И отвёртка лучше и нагляднее. Я не готов прям утверждать что во всех случаях, но там где можно - нужно =))
По проекту, я сделал шаблоны для чтения, что-то типа
test.tx - типизированный файл
UTF - это признак того что надо перекодировать туда и обратно.
Написал класс на коленке, сижу, пытаюсь прочитать по шаблону + у меня ещё название полей есть и даже описание таблица.
Можно будет документацию составлять во время работы.
Как нормально доделаю всё, может выложу. Там главное определиться вначале что надо, например я пишу для каждой переменной номер байта на чтение в структуре, чтобы не надо было морочится во время обхода.
И вторая часть - это работа. Мы не можем просто взять и скaзать load, например может быть 100.000(сто тысяч) записей. Нужно чтобы можно было и в тред запихнуть и прогрессбар подложить.
Спасибо Вам за ответ. Если по поводу древовидных динамических структур... Я могу сказать что прекрасно вас понимаю, даже с JSON работать тяжеловато, но меня могут и забить камнями =)))
Скажем так, по сравнению с JavaScript работать с динамикой не легко. Этому есть внятные и понятные объяснения, но я всё равно могу помечтать. И отвёртка лучше и нагляднее. Я не готов прям утверждать что во всех случаях, но там где можно - нужно =))
По проекту, я сделал шаблоны для чтения, что-то типа
test.tx - типизированный файл
Код: Выделить всё
D:\Project\umacro\testfiles\test.tx
test.tx:название:описание
id:string[5]:айди
name:string[25]:имя:UTF
str1:string[2]:строка1
str2:string[2]:строка2
str3:string[2]:строка3
str4:string[16]:строка4
UTF - это признак того что надо перекодировать туда и обратно.
Написал класс на коленке, сижу, пытаюсь прочитать по шаблону + у меня ещё название полей есть и даже описание таблица.
Можно будет документацию составлять во время работы.
Как нормально доделаю всё, может выложу. Там главное определиться вначале что надо, например я пишу для каждой переменной номер байта на чтение в структуре, чтобы не надо было морочится во время обхода.
И вторая часть - это работа. Мы не можем просто взять и скaзать load, например может быть 100.000(сто тысяч) записей. Нужно чтобы можно было и в тред запихнуть и прогрессбар подложить.
-
alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
Voltag
а почему просто не написать наследника от TDataSet который будет читать стркутуру файла из описания?
Как раз TDataSet предназначен для таких вещей. Получишь все возможности DB компонент. В том числе и поддержку перекодировок строк.
а почему просто не написать наследника от TDataSet который будет читать стркутуру файла из описания?
Как раз TDataSet предназначен для таких вещей. Получишь все возможности DB компонент. В том числе и поддержку перекодировок строк.
alexs писал(а):Voltag
а почему просто не написать наследника от TDataSet который будет читать стркутуру файла из описания?
Как раз TDataSet предназначен для таких вещей. Получишь все возможности DB компонент. В том числе и поддержку перекодировок строк.
Отличная идея. Спасибо большое за ответ!
to All
Ещё немножко данных. Я не смог, или плохо искал структуру типизированных файлов. (вдруг кому-то пригодиться)
Она такая: байт(вес в байтах записи)(HEX) + сама запись
05 00 00 00 00 01
вот пример записи в 5 байт
1 байт - это вес, остальные - это данные в 5 байт
далее, за ней идёт следующая запись, и так до конца файла, эх если бы был признак конца записи(блока из переменных), или признак начала, то можно было бы читать без схемы, хотя нужно было бы ещё пометка о типах.
Я о том, что не ожидал совсем байта под вес. Я думал о цели этого байта. Например, без этого байта записи могли бы быть больше 255 байт... или ответ скрыт в прошлом, не знаю.
я прочитал свои 10тысяч записей, поместил в табличку, всё получилось, теперь буду клепать схемы