В проекте какое-то время использовалась сериализация и было сохранено некоторое количество файлов с использованием BinaryFormatter. В какой-то момент сделали рефакторинг, перешли на другую систему версионности сборок, вынесли методы работы с файлами в отдельную сборку. Естественно десериализация данных вся посыпалась, файлы не читаются. Я наивный всегда предполагал, что в BinaryFormatter можно подставить свой биндер. Делаю биндер, а в биндер в BindToType() прилетают такие имена типов как System.RuntimeType или System.UnitySerializationHolder которые конечно же никуда не прибиндить. Ну и все не работает, данные не десериализуются. Есть ли какая-нибудь возможность в текущих версиях прочитать данные записанные в предыдущих версиях сборок?
Была проблема с бинарной (де)сериализацией -- требовала
определенную сборку, т.к. её метаданные куда-то там прописались.
Вроде победил тем,что подписывался на AppDomain.CurrentDomain.AssemblyResolve
и скармливал текущую сборку.
S>Была проблема с бинарной (де)сериализацией -- требовала S>определенную сборку, т.к. её метаданные куда-то там прописались. S>Вроде победил тем,что подписывался на AppDomain.CurrentDomain.AssemblyResolve S>и скармливал текущую сборку.
Нет, здесь сборка добавилась. Проблема прибиндить переименованные типы. Автоматом естественно оно не может, а свой биндер подключить невозможно, потому что a. BinaryFormatter использует привязку к типам internal в системных сборках, б. вообще теряется информация о типе, RuntimeType это потеря информации о типе.
И что мне теперь делать, бинарную сериализацию ф топку? Получается ее вообще лучше никогда не использовать? И вопрос более общий, поскольку вообще со всеми .NET сериалзациями вечные проблемы и костыли, нет ли какой-нибудь нормальной библиотеки на тему сериализации?
G>И что мне теперь делать, бинарную сериализацию ф топку? Получается ее вообще лучше никогда не использовать? И вопрос более общий, поскольку вообще со всеми .NET сериалзациями вечные проблемы и костыли, нет ли какой-нибудь нормальной библиотеки на тему сериализации?
Однозначно ф топку. Злейшее зло. Ссылку на protobuf уже дали.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, grosborn, Вы писали: G>>нет ли какой-нибудь нормальной библиотеки на тему сериализации?
QL>http://code.google.com/p/protobuf-net/
Издеваетесь? Или у неё уже всё хорошо с Generic, списками, XmlDocument и наследованными классами ?
G>>>нет ли какой-нибудь нормальной библиотеки на тему сериализации?
QL>>http://code.google.com/p/protobuf-net/
N_P>Издеваетесь? Или у неё уже всё хорошо с Generic, списками, XmlDocument и наследованными классами ?
Я когда-то писал сериализацию даже на 1С и ничего в ней сложного нет. Почему же лучшие умы человечества неспособны решить эту задачу?
Здравствуйте, grosborn, Вы писали:
G>Я когда-то писал сериализацию даже на 1С и ничего в ней сложного нет.
И сколько человек в мире пользовались этой Вашей 1С-сериализацией ?
G>Почему же лучшие умы человечества неспособны решить эту задачу?
Потому что для общего случая эта задача нерешаема.
Сериализуемые объекты существуют не в вакууме. Они связаны с другими объектами, как входящими в сериализуемый граф, так и сторонними. Семантика этого связывания у каждой программы своя. Что и является первопричиной всех проблем.
D>Потому что для общего случая эта задача нерешаема.
А поясните, пожалуйста, почему? Вроде кол-во объектов конечно, все суть граф, и можно
пройтись по всем узлам и сериализовать, попутно отмечая уже сериализованные
объекты...
D>Сериализуемые объекты существуют не в вакууме. Они связаны с другими объектами, как входящими в сериализуемый граф, так и сторонними. Семантика этого связывания у каждой программы своя. Что и является первопричиной всех проблем.
Кстати занимаясь обменом между различными конфигурациями, можно свести все эти графы к обычным таблицам и некой простейшей иерархической Базе данных.
и солнце б утром не вставало, когда бы не было меня
G>>Я когда-то писал сериализацию даже на 1С и ничего в ней сложного нет.
D>И сколько человек в мире пользовались этой Вашей 1С-сериализацией ?
Много.
G>>Почему же лучшие умы человечества неспособны решить эту задачу?
D>Потому что для общего случая эта задача нерешаема.
Ухты, вот ведь как оно, Петрович.
D>Сериализуемые объекты существуют не в вакууме. Они связаны с другими объектами, как входящими в сериализуемый граф, так и сторонними. Семантика этого связывания у каждой программы своя. Что и является первопричиной всех проблем.
Первопричиной проблем конкретно в моем случае и поднятых в этой ветке криворукость микрософтовских программистов десериализующих объекты приватных классов. Если бы не баги кастомного биндинга все бы работало. Лучшие умы человечества просто не правят баги скорее всего известные с первых .нет версий.
Что за минус? Это слепая вера в безбажность дотнета или лоялизм? Если так несогласен, прочитай первое сообщение и попробуй предложить решение проблемы.
Здравствуйте, grosborn, Вы писали:
G>Что за минус? Это слепая вера в безбажность дотнета или лоялизм?
Это знание того, что никакой криворукости программистов МС тут нет, если неправильное использование BinaryFormatter
G> Если так несогласен, прочитай первое сообщение и попробуй предложить решение проблемы.
Его тут уже предложили.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
G>>Что за минус? Это слепая вера в безбажность дотнета или лоялизм?
AVK>Это знание того, что никакой криворукости программистов МС тут нет, если неправильное использование BinaryFormatter
Зачем врать-то? У него только один способ использования, его нельзя неправильно применить. И у биндера один способ применения, без вариантов, но он не работает. Или варианты озвученные ниже ты считаешь правильным использованием?
G>> Если так несогласен, прочитай первое сообщение и попробуй предложить решение проблемы.
AVK>Его тут уже предложили.
Зачем врать-то? Решения не было, даже мыслей как это можно решить не было озвучено. Есть файлы, есть переименованные типы в новой сборке. Ну я не знаю, патчить файл скажем, или лезть в исходники и цепляться рефлекшеном, или самое простое сделать фэйковые десериализуемые объекты с типами соответствующими старым сборкам, а потом из них данные копировать, варианты есть что лучше я не знаю. Предложение перейти на другой сериализатор это не решение, а скорее признание что прямого решения нет.
Здравствуйте, grosborn, Вы писали:
G>Зачем врать-то?
Слишком сильное утверждение в данной ситуации, не находишь?
G> У него только один способ использования, его нельзя неправильно применить.
Какой такой один способ?
G> И у биндера один способ применения, без вариантов, но он не работает.
У меня почему то работает.
G> Или варианты озвученные ниже ты считаешь правильным использованием?
Я считаю правильным использовать протокол с явным контрактом, например Protobuf. А BinaryFormatter предназначен прежде всего для ремоутинга (особенно в части кроссдоменного взаимодействия), где расползание сборок с контрактами недопустимо по куче других причин или просто невозможно, поэтому он может смело полагаться на внутренние детали реализации. Если же кто то решил использовать его вместо стандартизованных бинарных форматов или БД, то он ССЗБ, а не программисты в МС виноваты.
G>Решения не было, даже мыслей как это можно решить не было озвучено.
Было сказано неоднократно, что следует заменить BF на что то с управляемым и документированным форматом. Формат BF не документирован специально, чтобы на него ни в коем случае не закладывались.
G> Есть файлы, есть переименованные типы в новой сборке.
Простое переименование биндер отработает без проблем. А вот если данные по другому стали по классам раскладываться, тут уже все.
G>Предложение перейти на другой сериализатор это не решение, а скорее признание что прямого решения нет.
Это именно что правильное решение.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, grosborn, Вы писали:
G>елаю биндер, а в биндер в BindToType() прилетают такие имена типов как System.RuntimeType или System.UnitySerializationHolder которые конечно же никуда не прибиндить.
А зачем их биндить ручками, когда достаточно вернуть null:
// System.Runtime.Serialization.Formatters.Binary.ObjectReaderinternal Type Bind(string assemblyString, string typeString)
{
Type type = null;
if (this.m_binder != null) // m_binder - SerializationBinder
{
type = this.m_binder.BindToType(assemblyString, typeString); // Ваш код.
}
if (type == null)
{
type = this.FastBindToType(assemblyString, typeString); // Стандартная логика.
}
return type;
}
Ага, забавно, тебя плюсуют твои братья-лоялисты совершенно не читая что ты написал.
G>>Зачем врать-то?
AVK>Слишком сильное утверждение в данной ситуации, не находишь?
Так ведь бездумно защищаешь мс с помощью самопридуманных аргументов, заявлешь о каком-то знании которого на самом деле нет. Как это еще называется?
G>> У него только один способ использования, его нельзя неправильно применить.
AVK>Какой такой один способ?
Метод Serialize() он такой, опций практически нет. Для тебя это новость?
G>> И у биндера один способ применения, без вариантов, но он не работает.
AVK>У меня почему то работает.
Частный случай, мог бы и сам догадаться. Не используешь какие-то проблемные типы объектов. Истина где-то опять пролетает мимо тебя.
G>> Или варианты озвученные ниже ты считаешь правильным использованием?
AVK>Я считаю правильным использовать протокол с явным контрактом, например Protobuf. А BinaryFormatter предназначен прежде всего для ремоутинга (особенно в части кроссдоменного взаимодействия), где расползание сборок с контрактами недопустимо по куче других причин или просто невозможно, поэтому он может смело полагаться на внутренние детали реализации. Если же кто то решил использовать его вместо стандартизованных бинарных форматов или БД, то он ССЗБ, а не программисты в МС виноваты.
Видишь ли, сериализацию не в МС придумали и то что ты пишешь, ограничение на использование только в ремотинг, да еще и без расползание сборок, это ограничения кривой частной реализации в .НЕТ. В других реализациях, не в .нет таких ограничений нет и оно работает. И не требуется такого технического маразма как сохранение картинок в xml или в бд патамушта у нас бинарная сериализация как-то вот так работает. Хочешь знать как это должно быть сделано правильно?
BinaryFormatter это абстракция и, о новость для тебя, не должна зависеть от того, хочешь ли ты сериализант сохранить в файл или отправить его по сети и каким способом, и чем его хочешь прочитать. Функция привязки к версии и ключу сборки, которая сейчас прибита гвоздями к сериализации каждого объекта, эта функция должна быть внешней или опциональной, если она вообще нужна. Я всегда сериализовал без этих мудрствований и всегда все работало всего-лишь на идентификаторе формата пакета.
Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
G>>Решения не было, даже мыслей как это можно решить не было озвучено.
AVK>Было сказано неоднократно, что следует заменить BF на что то с управляемым и документированным форматом. Формат BF не документирован специально, чтобы на него ни в коем случае не закладывались.
Следовало бы 1) допускать опционально привязку только по имени метаданных. Знаю что можно сделать через биндер, но это должно быть стандартной опцией. 2) исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов. Откуда только он их берет, их нет в сериализуемых данных.
И, о чудо, работала бы и стандартная бинарная сериализация.
G>> Есть файлы, есть переименованные типы в новой сборке.
AVK>Простое переименование биндер отработает без проблем. А вот если данные по другому стали по классам раскладываться, тут уже все.
G>>Предложение перейти на другой сериализатор это не решение, а скорее признание что прямого решения нет.
AVK>Это именно что правильное решение.
Это следствие кривизны чьих-то рук, не будем показывать пальцем, хотя это конечно же МС.
G>>Делаю биндер, а в биндер в BindToType() прилетают такие имена типов как System.RuntimeType или System.UnitySerializationHolder которые конечно же никуда не прибиндить.
S>А зачем их биндить ручками, когда достаточно вернуть null:
Я всяко пробовал и null тоже. У нутрях у него неонка и никак не работает. Там принципиально не получается десериализовать, потому что видимо баг при сериализации, сериализуются объекты которые потом нельзя прибиндить биндером, а без биндера только фейковыми объектами, но их строить это лес и ломать текущую структуру классов потому что нельзя один класс отдельно заменить на фэйковый. В общем наверняка как-то это можно, но связано с дополнительными головняками и я пока забросил это дело.
Здравствуйте, grosborn, Вы писали:
AVK>>Слишком сильное утверждение в данной ситуации, не находишь? G>Так ведь бездумно защищаешь мс с помощью самопридуманных аргументов, заявлешь о каком-то знании которого на самом деле нет.
1) Бездумно — это твои личные заблуждения
2) Я не защищаю МС
3) О каком знании, как тебе показалось, я заявил?
G> Как это еще называется?
Ну уж никак не враньем.
G>>> У него только один способ использования, его нельзя неправильно применить. AVK>>Какой такой один способ? G>Метод Serialize() он такой, опций практически нет. Для тебя это новость?
Это не способ использования.
G>>> И у биндера один способ применения, без вариантов, но он не работает. AVK>>У меня почему то работает. G>Частный случай
Нет, просто я BF применяю правильно.
G>, мог бы и сам догадаться. Не используешь какие-то проблемные типы объектов. Истина где-то опять пролетает мимо тебя.
А может мимо тебя?
G>Видишь ли, сериализацию не в МС придумали
И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков. Вот XmlSerializer или DataContractSerializer использовать можно, потому что формат сериализованных данных явным образом специфицируется. К сожалению, оба они текстовые, поэтому здесь и предложили использовать Protobuf-Net.
G>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
Какие именно?
G>исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов.
Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать. И биндер сделан вовсе не для того чтобы с версиями воевать, а для сериализации MBR объектов (через биндер Transparent Proxy зам еняется на ObjRef и обратно). То, что ты решил его использовать не по назначению — твоя личная проблема.
G> Откуда только он их берет, их нет в сериализуемых данных.
Есть. Точнее были.
AVK>>Это именно что правильное решение. G>Это следствие кривизны чьих-то рук
Конечно, того кто для долго живущих данных решил использовать BF.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>3) О каком знании, как тебе показалось, я заявил?
Прочитай свои же посты и найдешь упоминанием о тайном знании.
G>> Как это еще называется?
AVK>Ну уж никак не враньем.
Вообще-то тут может быть три варианта, вранье, глупость и заблуждение. Выбирай.
G>>>> У него только один способ использования, его нельзя неправильно применить. AVK>>>Какой такой один способ? G>>Метод Serialize() он такой, опций практически нет. Для тебя это новость?
AVK>Это не способ использования.
О, это аргумент, да еще какой. Твой папа случайно не депутат, не?
AVK>Нет, просто я BF применяю правильно.
О да, метод один, опций нет, но ты его применяешь правильно, а другие нет. Дискуссия вышла на новый уровень.
G>>Видишь ли, сериализацию не в МС придумали
AVK>И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков.
До тебя не доходит что это и есть кривизна. И то что для типовых задач применяется внешняя библиотека патамушта якобы внутренняя сильно правильная и ее использовать нельзя, тебя совсем не убеждает. И то что для сериализации нет разницы для чего ты ее используешь, ты конечно не знаешь.
G>>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
AVK>Какие именно?
Все.
G>>исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов.
AVK>Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать.
Опять бла-бла-бла, подтвердить свои слова ты не можешь.
AVK>И биндер сделан вовсе не для того чтобы с версиями воевать, а для сериализации MBR объектов (через биндер Transparent Proxy зам еняется на ObjRef и обратно). То, что ты решил его использовать не по назначению — твоя личная проблема.
Биндер якобы не для того что бы биндить. Ага-ага, мы верим, ага.
G>> Откуда только он их берет, их нет в сериализуемых данных.
AVK>Есть. Точнее были.
Не было там этих классов, там достаточно простая структура объектов и они там не нужны.
AVK>>>Это именно что правильное решение. G>>Это следствие кривизны чьих-то рук
AVK>Конечно, того кто для долго живущих данных решил использовать BF.
И это работает, но только в других языках и в других библиотеках. И только в .НЕТ с их прямыми руками это не работает. Ты случайно не в МС работаешь?
Здравствуйте, grosborn, Вы писали:
G>Прочитай свои же посты и найдешь упоминанием о тайном знании.
Ты не виляй, ты ответь на вопрос.
G>>> Как это еще называется? AVK>>Ну уж никак не враньем. G>Вообще-то тут может быть три варианта, вранье, глупость и заблуждение. Выбирай.
Здесь может быть еще куча вариантов. Например, что это ты заблуждаешься, а не я.
G>>>>> У него только один способ использования, его нельзя неправильно применить. AVK>>>>Какой такой один способ? G>>>Метод Serialize() он такой, опций практически нет. Для тебя это новость? AVK>>Это не способ использования. G>О, это аргумент, да еще какой. Твой папа случайно не депутат, не?
О, уже на личности перешел. Ответь на простой вопрос — какой один способ использования ты упоминал.
AVK>>Нет, просто я BF применяю правильно. G>О да, метод один, опций нет, но ты его применяешь правильно, а другие нет.
Именно. Потому что метод это не способ применения. Мне так кажется, что ты просто не понимаешь вопроса. Способ применения ака use case предполагает в том числе конкретную цель использования функционала. Так вот — твоя цель негодная. При чем тут единственность метода и отсутствие у него параметров?
AVK>>И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков.
G>До тебя не доходит что это и есть кривизна
Это до тебя не доходит, что у любого кода есть область применения.
G>>>Так что все эти твои заявки верны с точностью до наоборот и просто смешны. AVK>>Какие именно? G>Все.
То есть ни одной конкретной ты указать не можешь. ЧТД.
G>>>исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов. AVK>>Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать. G>Опять бла-бла-бла, подтвердить свои слова ты не можешь.
А зачем их подтверждать, если ты сам на грабли уже наступил и прочувствовал неверность своих предположений на практике? Или, может, ты расскажешь, как следовало спроектировать ремоутинг, чтобы он обходился без сериализации приватных данных?
G>Биндер якобы не для того что бы биндить. Ага-ага, мы верим, ага.
Не надо верить. Надо открыть исходники бинарного remoting channel и посмотреть на тамошний биндер.
G>>> Откуда только он их берет, их нет в сериализуемых данных. AVK>>Есть. Точнее были. G>Не было там этих классов
Ну конечно, BF их сам придумал И Unity он тоже сам откуда то заимпортировал.
G>, там достаточно простая структура объектов и они там не нужны.
А ты просмотрел все приватные поля всего графа этих объектов?
AVK>>>>Это именно что правильное решение. G>>>Это следствие кривизны чьих-то рук AVK>>Конечно, того кто для долго живущих данных решил использовать BF. G>И это работает
Это НЕ работает.
G>но только в других языках и в других библиотеках. И только в .НЕТ с их прямыми руками это не работает.
В дотнете тоже все работает. Надо просто подбирать правильный инструмент.
G> Ты случайно не в МС работаешь?
Нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Ни одного аргумента от тебя не поступило, демагогия, намеки на единственно правильное использование, отрицание фактов и сравнений. Достойный лидер для этого ресурса.
AVK>И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков. Вот XmlSerializer или DataContractSerializer использовать можно, потому что формат сериализованных данных явным образом специфицируется. К сожалению, оба они текстовые, поэтому здесь и предложили использовать Protobuf-Net.
Ты забыл ещё JSON! Их тоже вроде 2-3 штуки!!! публичных должно быть, сам видел
Не находишь что именно то что ты написал как-бы намекает что топик-стартер прав? Всё ли правильно, если так много разных! сериализаций, и, внезапно, ты сам советуешь стороннюю для типовой задачи?
В .NET год за годом лепят сериализации по одной для каждого убогого случая, вместо одной сделанной с умом и с продуманной архитектурой. Нужно было разделить ответственность между классами и вместо захардкоженной несколько раз фигни на аттрибутах создать набор перечислителей полей или свойств отдельно, отделить форматтеры от перечислителей и реализовать самые основные вроде XML, Binary, JSON, SOAP, Protobuf и т.п., позволить передавать десериализатору биндер и фабрику для создания объектов или привязки их к существующим, отделить группу неких мапперов или migration helper'ов для разруливания проблем с версионностью. Короче подумать перед тем как делать. А то что сейчас налеплено — захардкодили поддержку "своих" аттрибутов и вытащили наружу пару методов для создания видимости возможности расширения, и так 5-6 раз, это несерьёзно.
G>>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
AVK>Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать. И биндер сделан вовсе не для того чтобы с версиями воевать, а для сериализации MBR объектов (через биндер Transparent Proxy зам еняется на ObjRef и обратно). То, что ты решил его использовать не по назначению — твоя личная проблема.
Это вы ещё в ракете не смотрели использовании ISerializationSurrogate не копались , тот же биндер вид сбоку.
Здравствуйте, hi_octane, Вы писали:
_>Ты забыл ещё JSON! Их тоже вроде 2-3 штуки!!! публичных должно быть, сам видел
Я не забыл. Во-первых в самом фреймворке их вроде нет (MVC вроде сейчас как то отдельно), во-вторых это текстовый формат.
_>Не находишь что именно то что ты написал как-бы намекает что топик-стартер прав?
В чем он прав? В том что BF использовал там где ненужно, или в том что считает что BF не должен сериализовать на основании приватной структуры?
_> Всё ли правильно, если так много разных! сериализаций, и, внезапно, ты сам советуешь стороннюю для типовой задачи?
Я нигде не советовал одну конкретную сериализацию.
_>В .NET год за годом лепят сериализации по одной для каждого убогого случая, вместо одной сделанной с умом и с продуманной архитектурой.
Потому что абсолютно универсальная сериализация не нужна. Но если ты так уверен в обратном — можешь начать проект своей, правильной. Если это будет нужно ощутимому количеству людей тебя поддержат.
_>Это вы ещё в ракете не смотрели использовании ISerializationSurrogate не копались , тот же биндер вид сбоку.
Копался. Я тебе больше скажу, в свое время фактически полностью пришлось переписать брата близнеца BF — SoapFormatter, так что я в теме, не переживай. Потроха ремоутинга там торчат отовсюду.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, grosborn, Вы писали:
G>Ни одного аргумента от тебя не поступило, демагогия, намеки на единственно правильное использование, отрицание фактов и сравнений. Достойный лидер для этого ресурса.
Эмм... вообще-то BinaryFormatter действительно не подходит для долговременного хранения данных, особенно если планируется что схема данных или используемый фреймворк будет меняться.
В официальной документации ограничиваются полунамёками, например, вот тут:
To ensure proper versioning behavior, follow these rules when modifying a type from version to version:
* Never remove a serialized field.
* Never apply the NonSerializedAttribute attribute to a field if the attribute was not applied to the field in the previous version.
* Never change the name or the type of a serialized field.
...
Не, конечно можно потратить время на изучение и поддержку вот этого, но я предпочёл бы хранить данные в xml/лёгковесной СУБД.
Здравствуйте, Sinix, Вы писали:
S>Не, конечно можно потратить время на изучение и поддержку вот этого
Не стоит имхо — MSOSD это отмазка для суда, а не важный технический документ. На крайняк есть же бинарный формат в WCF, хоть и XML-подобной структуры, если уж так не хочется внешнюю библиотеку.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Sinix, Вы писали:
S>>Не, конечно можно потратить время на изучение и поддержку вот этого
AVK>Не стоит имхо — MSOSD это отмазка для суда, а не важный технический документ. На крайняк есть же бинарный формат в WCF, хоть и XML-подобной структуры, если уж так не хочется внешнюю библиотеку.
Интересно почему не сделать сразу бинарную сериализацию на уровне локальной БД. Где есть таблица типов. Поля с объектами состоят из двух полей таблица типа и номер строки в этой таблице.
Все валуе типы хранятся в бинарном виде а всякие строки и прочие блобы в таблицах типа блоб. Так мы получаем набор полей и можем сравнивать версии и по сути и иметь возможность преобразовывать из одной версии в другую или просто не заполнять отсутствующие поля. При этом объем такой БД будет небольшим. Лишние байты это незаполненные до конца страницы. Так это будет даже легче чем XML сериализация а по объему значительно меньше.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Интересно почему не сделать сразу бинарную сериализацию на уровне локальной БД.
Почему не сделать? Для сериализации в БД есть целая пачка ORM от навороченных до очень легких и даже некоторое количество ООБД и NoSQL движков. Только такие сериализаторы очень сильно отличаются от сериализаторов в поток по очевидным причинам.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
_>>Не находишь что именно то что ты написал как-бы намекает что топик-стартер прав? AVK>В чем он прав? В том что BF использовал там где ненужно, или в том что считает что BF не должен сериализовать на основании приватной структуры?
В том что нормальной сериализации в общем нет, есть штук 6 каких-то других.
_>> Всё ли правильно, если так много разных! сериализаций, и, внезапно, ты сам советуешь стороннюю для типовой задачи? AVK>Я нигде не советовал одну конкретную сериализацию.
Я считаю правильным использовать протокол с явным контрактом, например Protobuf.
, наверное я неправильно истолковал, это был не совет совсем, а наборот, сорри.
_>>В .NET год за годом лепят сериализации по одной для каждого убогого случая, вместо одной сделанной с умом и с продуманной архитектурой. AVK>Потому что абсолютно универсальная сериализация не нужна.
Несколько кривых нужнее. Понял. Больше в это болото со своим уставом лезть не буду
AVK>Но если ты так уверен в обратном — можешь начать проект своей, правильной. Если это будет нужно ощутимому количеству людей тебя поддержат.
Спасибо, как флеймер со стажем, я в сперва добейся не играю Но если вдруг сюда придёт кто-то из MS с вопросом как запилить сериализацию так чтоб в этот раз точно нормально получилось, думаю все прошаренные челы поотвечают и будет наконец щасте.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, grosborn, Вы писали:
G>> Или варианты озвученные ниже ты считаешь правильным использованием?
AVK>Я считаю правильным использовать протокол с явным контрактом, например Protobuf. А BinaryFormatter предназначен прежде всего для ремоутинга (особенно в части кроссдоменного взаимодействия), где расползание сборок с контрактами недопустимо по куче других причин или просто невозможно, поэтому он может смело полагаться на внутренние детали реализации. Если же кто то решил использовать его вместо стандартизованных бинарных форматов или БД, то он ССЗБ, а не программисты в МС виноваты.
Я как-то ни разу не фанат RSDN-админов (а то и наоборот), но вот с выделенным соглашусь на все 100 промилле. Бинарный форматер — как карман в штанах, всё входит и выходит. Но вот надел другие штаны — там карман уже не обязан быть таким же, как в предыдущих (хотя может и повезти, но надеяться не надо).
Здравствуйте, hi_octane, Вы писали:
_>В том что нормальной сериализации в общем нет
Начать следует с определения нормальной сериализации. Лично у меня есть большие сомнения в том, что нужна сверхуниверсальная, потому что требования в разных юзкейсах отличаются очень сильно.
AVK>>Я нигде не советовал одну конкретную сериализацию. _>
Я считаю правильным использовать протокол с явным контрактом, например Protobuf.
Значения слова "например" понятно?
AVK>>Потому что абсолютно универсальная сериализация не нужна. _>Несколько кривых нужнее
Осталось доказать, что все сериализации в фреймворке кривые.
AVK>>Но если ты так уверен в обратном — можешь начать проект своей, правильной. Если это будет нужно ощутимому количеству людей тебя поддержат. _>Спасибо, как флеймер со стажем, я в сперва добейся не играю
Это не сперва добейся, это вполне жизненный совет.
_> Но если вдруг сюда придёт кто-то из MS с вопросом как запилить сериализацию так чтоб в этот раз точно нормально получилось, думаю все прошаренные челы поотвечают и будет наконец щасте.
Думай.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> Интересно почему не сделать сразу бинарную сериализацию на уровне локальной БД.
AVK>Почему не сделать? Для сериализации в БД есть целая пачка ORM от навороченных до очень легких и даже некоторое количество ООБД и NoSQL движков. Только такие сериализаторы очень сильно отличаются от сериализаторов в поток по очевидным причинам.
А Бд это и есть поток, только не последовательный. Просто бОльшая абстракция. Просто в Net нельзя использовать адрес в памяти а так просто построить индекс.
Или придется для каждого тип создавать Хэш таблицу и ключем будет количество Записей В ХашТаблице. Перед записью проверяем есть ли такой объект в Хэш таблице если есть заносим в Хэш таблицу и записываем дальше этот объект и возвращаем ключ, если уже есть просто возвращаем ключ. Такая же операция и при десериализации. Просто вместо Хэш таблиц будут массивы (размер таблиц нам известны. И там не нужно навороченные бд. Ключ это номер записи а списки можно хранить ввиде однонаправленных списков. Для null использовать 0 или -1.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> А Бд это и есть поток, только не последовательный.
AVK>Нет, БД это не поток, потому что рандомный доступ без перемещения курсора, и потому что индексный поиск как минимум.
Ну номер записи это не совсем поиск (хотя внутри нужно найти страницу). Если записи будут иметь поля только валуе типов то и ссылок не будет.
Но почему наряду с существующими типами сериализации не сделать сериализацию в БД? При чем она будет еще и компактнее бинарной сериализации так как поле для типа может иметь тип int (номер таблицы в БД).
Описание полей каждой таблицы тоже зашиты в определенные таблицы БД. По сути это более универсальное решение, чем существующие.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Ну номер записи это не совсем поиск (хотя внутри нужно найти страницу). Если записи будут иметь поля только валуе типов то и ссылок не будет.
Если бы у бабушки был ...
S>Но почему наряду с существующими типами сериализации не сделать сериализацию в БД?
Потому что она уже есть, называется ORM. Если же писать в БД как в файл, всегда одним куском весь граф, то тогда и БД не нужна.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Ну номер записи это не совсем поиск (хотя внутри нужно найти страницу). Если записи будут иметь поля только валуе типов то и ссылок не будет.
AVK>Если бы у бабушки был ...
S>>Но почему наряду с существующими типами сериализации не сделать сериализацию в БД?
AVK>Потому что она уже есть, называется ORM. Если же писать в БД как в файл, всегда одним куском весь граф, то тогда и БД не нужна.
ORM это не то. Например тип объекта могут быть потомки а может и просто поле типа Object. И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию. Второе сама БД может быть максимально облегченной и не меняться со временем и храниться в Одном файле в какой нибудь System.Runtime. При этом скорость сериализации десериализации будет достаточно высока и универсальна
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> ORM это не то.
И в чем отличие? Что ORM не позволяет тебе сделать?
S> Например тип объекта могут быть потомки а может и просто поле типа Object.
И что?
S> И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию.
А ORM, по твоему, как работает?
S> Второе сама БД может быть максимально облегченной
ORM этому не препятствуют. А есть специальные ООБД, в которых ORM встроен.
S>При этом скорость сериализации десериализации будет достаточно высока и универсальна
Угу, берешь linq2db, и по скорости сериализации BF остается в глубокой попе.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> ORM это не то.
AVK>И в чем отличие? Что ORM не позволяет тебе сделать?
Ну тем, что это простейшее отображение, где не нужно ни каких транзакций, никаких блокировок (при условии записи в одном потоке). S>> Например тип объекта могут быть потомки а может и просто поле типа Object.
AVK>И что?
S>> И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию.
AVK>А ORM, по твоему, как работает?
Особо не вникал в суть, но например проблема в 1С где поле может быть ссылкой на объекты из разных таблиц вроде как не совсем решена в реляционных БД.
Хотя могу ошибаться. Там поле должно иметь структуру таблица, индекс
S>> Второе сама БД может быть максимально облегченной
AVK>ORM этому не препятствуют. А есть специальные ООБД, в которых ORM встроен.
Ну так нужно взять одну такую БД и движок зашить в общую сборку. Так как не нужны индексы, транзакции и блокировки, база там максимально облегченная.
S>>При этом скорость сериализации десериализации будет достаточно высока и универсальна
AVK>Угу, берешь linq2db, и по скорости сериализации BF остается в глубокой попе.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>И в чем отличие? Что ORM не позволяет тебе сделать? S> Ну тем, что это простейшее отображение, где не нужно ни каких транзакций, никаких блокировок (при условии записи в одном потоке).
Транзакции и блокировки вовсе не обязательный признак ОРМ. Ты путаешь ОРМ и РСУБД.
S>>> И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию. AVK>>А ORM, по твоему, как работает? S> Особо не вникал в суть
Так вникни.
S>, но например проблема в 1С
В твоем мире ничего кроме 1С не существует?
AVK>>ORM этому не препятствуют. А есть специальные ООБД, в которых ORM встроен. S> Ну так нужно взять одну такую БД и движок зашить в общую сборку.
Так и такое есть.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
S>> Ну так нужно взять одну такую БД и движок зашить в общую сборку.
AVK>Так и такое есть.
Почему тогда такой сериализации нет вместе с XML и Бинарной? Там ничего сложного нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Так и такое есть. S>> Почему тогда такой сериализации нет вместе с XML и Бинарной?
AVK>А зачем вместе с XML и бинарной?
Я так понимаю, что сериализация объектов и доступ к приватным полям должен накладывать ограничения и доступ может быть ограничен или нужно самому выстраивать доступ через рефлексию.
Такие механизмы можно встраивать в систему. Вплоть до кодогенерации кода чтения и записи.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>А зачем вместе с XML и бинарной? S>Я так понимаю, что сериализация объектов и доступ к приватным полям должен накладывать ограничения и доступ может быть ограничен или нужно самому выстраивать доступ через рефлексию.
Долго обсуждали то, как плохо приватные поля учитывать без сериализации, и пришли опять к этому.
S>Такие механизмы можно встраивать в систему.
В какую систему и зачем?
S> Вплоть до кодогенерации кода чтения и записи.
Для кодогенерации ничего в систему встраивать не надо.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>А зачем вместе с XML и бинарной? S>>Я так понимаю, что сериализация объектов и доступ к приватным полям должен накладывать ограничения и доступ может быть ограничен или нужно самому выстраивать доступ через рефлексию.
AVK>Долго обсуждали то, как плохо приватные поля учитывать без сериализации, и пришли опять к этому.
А как от них отказаться, если гетеры и сетеры могут зависеть не от поля, а от набора полей. Плохо это или хорошо.
S>>Такие механизмы можно встраивать в систему.
AVK>В какую систему и зачем?
S>> Вплоть до кодогенерации кода чтения и записи.
AVK>Для кодогенерации ничего в систему встраивать не надо.
Вот смотрю я на BF. Там конечно черт ногу сломит. Но имя System.Runtime.Serialization.Formatters.Binary.BinaryFormatter как бы намекает на рантайм. Но вот этот BF должен быть не в стрим а в БД.
Мне на самом деле не понятно, что такого зашитого механизма нет. Хотя он очевиден.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А как от них отказаться
Есть разные варианты.
S>, если гетеры и сетеры могут зависеть не от поля, а от набора полей.
Зачем в DTO геттеры и сеттеры, зависящие от нескольких полей?
AVK>>Для кодогенерации ничего в систему встраивать не надо. S> Вот смотрю я на BF. Там конечно черт ногу сломит. Но имя System.Runtime.Serialization.Formatters.Binary.BinaryFormatter как бы намекает на рантайм.
BF использует рефлекшен, это очевидно. А вот XmlSerializer, DataContractSerializer, linq2db используют кодогенерацию.
S> Но вот этот BF должен быть не в стрим а в БД. Мне на самом деле не понятно, что такого зашитого механизма нет.
Есть. Entity Framework называется.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>BF использует рефлекшен, это очевидно. А вот XmlSerializer, DataContractSerializer, linq2db используют кодогенерацию.
Потому, что там все элементарно со свойствами. Намного сложнее, когда есть приватные поля и иерархия.
S>> Но вот этот BF должен быть не в стрим а в БД. Мне на самом деле не понятно, что такого зашитого механизма нет.
AVK>Есть. Entity Framework называется.
И какую встроеную БД они используют? Как легко можно воспользоваться?
Хотелось бы так же как и BF
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>BF использует рефлекшен, это очевидно. А вот XmlSerializer, DataContractSerializer, linq2db используют кодогенерацию. S> Потому, что там все элементарно со свойствами.
Нет, не потому.
S> Намного сложнее, когда есть приватные поля и иерархия.
Они все в той или иной мере понимают иерархию, а приватные поля в сериализации, которой важен формат, не нужны.
AVK>>Есть. Entity Framework называется. S> И какую встроеную БД они используют?
Любую, для которой есть EF ADO.NET провайдер. Вот списочек таких провайдеров — http://msdn.microsoft.com/en-us/data/dd363565.aspx. Из встроенных там sqlite и fb embedded.
Плюс МСный вариант — SQL CE.
S> Как легко можно воспользоваться?
Легко.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Любую, для которой есть EF ADO.NET провайдер. Вот списочек таких провайдеров — http://msdn.microsoft.com/en-us/data/dd363565.aspx. Из встроенных там sqlite и fb embedded. AVK>Плюс МСный вариант — SQL CE.
SQL CE это супер навороченный вариант для целей сериализации. Это стрельба из пушки по воробьям. Там не надо индексов, ссылки это номер позиция в Таблице, Массив ввиде двух таблиц ппервой ссылка на первый элемент и количество, тоже касается и строк. Так как не надо удалять сама БД элементарная. S>> Как легко можно воспользоваться?
AVK>Легко.
Можно примерчик?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Там не надо индексов
AVK>Если не надо индексов и удаления, то и БД не нужна. Совсем.
А как ты будешь хранить таблицы? Вся прелесть БД, что типы сгруппированы по таблицам и не нужно при записи указывать тип.
Но для сериализации десериализации нужны дополнительные данные в памяти (при сериализации это Хэш таблицы по типам хранящие объект и номер записи в таблице) при десериализации просто массив хранящий ссылку на объект. Все элементарно. При этом можно сравнивать текущую версию с сериализованной версией. Это все лучшее из XML и бинарной сериализации. AVK>>>Легко. S>> Можно примерчик?
AVK>http://bit.ly/11l02Ez
Угу это так же элементарно как BF. Нужен полный аналог BF, только внутри пишется не последовательно, а раскладывается по таблицам.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А как ты будешь хранить таблицы?
В файле.
S> Вся прелесть БД, что типы сгруппированы по таблицам
Прелесть БД в наличии индексов и поиска по ним, а так же возможности модификации отдельных записей, а не перезаписи графа целиком. Для просто структурированного решения есть много всяких вариантов, например XML.
AVK>>http://bit.ly/11l02Ez S> Угу это так же элементарно как BF. Нужен полный аналог BF
Пишется на коленке за 10 минут.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> А как ты будешь хранить таблицы?
AVK>В файле.
S>> Вся прелесть БД, что типы сгруппированы по таблицам
AVK>Прелесть БД в наличии индексов и поиска по ним, а так же возможности модификации отдельных записей, а не перезаписи графа целиком. Для просто структурированного решения есть много всяких вариантов, например XML.
В котором пишется слишком много лишних букв. А зачем нужна модификация при сериализации? Я уверяю, что сериализация в Таблицы намного эффективнее по скорости записи и чтения чем из XML и при этом будет значительно меньше по размеру. AVK>>>http://bit.ly/11l02Ez S>> Угу это так же элементарно как BF. Нужен полный аналог BF
AVK>Пишется на коленке за 10 минут.
А зачем тратить эти 10 минут? C BF не тратится ни ничего лишнего. Все из каропки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> В котором пишется слишком много лишних букв.
http://en.wikipedia.org/wiki/Protocol_Buffers
В БД, кстати, тоже будет "много лишних букв", потому что формат хранения затачивается под масштабные модификации и минимизацию фрагментации в процессе.
S> А зачем нужна модификация при сериализации?
Если не нужна, то и БД тоже не нужна.
S> Я уверяю, что сериализация в Таблицы намного эффективнее по скорости записи и чтения чем из XML
Ты не уверяй, ты проверь.
S> и при этом будет значительно меньше по размеру.
Это тоже проверь
AVK>>Пишется на коленке за 10 минут. S>А зачем тратить эти 10 минут?
Затем, что задача сериализации графа объектов в БД одним разом не самая встречающаяся. Вот скажи, можешь ты некоторое количество юзкейсов описать для нее, раз так агитируешь за универсальный сериализатор?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> В котором пишется слишком много лишних букв.
AVK>http://en.wikipedia.org/wiki/Protocol_Buffers AVK>В БД, кстати, тоже будет "много лишних букв", потому что формат хранения затачивается под масштабные модификации и минимизацию фрагментации в процессе.
S>> А зачем нужна модификация при сериализации?
AVK>Если не нужна, то и БД тоже не нужна.
БД это набор Таблиц, в том числе и таблицы описания типов. Смысл такой сериализации когда сериализуется массив.
AVK>>>Пишется на коленке за 10 минут. S>>А зачем тратить эти 10 минут?
AVK>Затем, что задача сериализации графа объектов в БД одним разом не самая встречающаяся. Вот скажи, можешь ты некоторое количество юзкейсов описать для нее, раз так агитируешь за универсальный сериализатор?
Например для передачи данных между приложениями. В том числе например между сервером и клиентом. Например есть мобильное приложение и сервер. Для сохранения состояния для аварийного восстановления или окончания работы
Для обмена между конфигурациями. Там правда нет ссылок, так как ключи в полях. Это всяко лучше чем текстовые файлы и XML. При этом можно использовать в SQL вместо булков.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Если не нужна, то и БД тоже не нужна. S> БД это набор Таблиц, в том числе и таблицы описания типов.
А XML — набор тегов. Дальше что?
S> Смысл такой сериализации когда сериализуется массив.
Ты сам то понял что сказал?
AVK>>Затем, что задача сериализации графа объектов в БД одним разом не самая встречающаяся. Вот скажи, можешь ты некоторое количество юзкейсов описать для нее, раз так агитируешь за универсальный сериализатор? S> Например для передачи данных между приложениями.
БД для передачи данных между приложениями? Жоско. А как это должно выглядеть? Скидываем граф объектов в БД, потом файл с БД передаем по сети?
S>Для обмена между конфигурациями.
Каких таких конфигураций? 1С что ли? При чем тут тогда дотнет?
S> Там правда нет ссылок, так как ключи в полях.
Ключи есть а индексов нет?
S> Это всяко лучше чем текстовые файлы и XML.
Чем лучше?
S> При этом можно использовать в SQL вместо булков.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Если не нужна, то и БД тоже не нужна. S>> БД это набор Таблиц, в том числе и таблицы описания типов.
AVK>А XML — набор тегов. Дальше что?
То есть БД на XML это по твоему нормально?
S>> Смысл такой сериализации когда сериализуется массив.
AVK> Ты сам то понял что сказал?
Наборы данных. Так пойдет?
AVK>>>Затем, что задача сериализации графа объектов в БД одним разом не самая встречающаяся. Вот скажи, можешь ты некоторое количество юзкейсов описать для нее, раз так агитируешь за универсальный сериализатор? S>> Например для передачи данных между приложениями.
AVK>БД для передачи данных между приложениями? Жоско. А как это должно выглядеть? Скидываем граф объектов в БД, потом файл с БД передаем по сети?
Да а в чем сложность? При этом обмен через MXL с сотнями мегабайт это нормально? S>>Для обмена между конфигурациями.
AVK>Каких таких конфигураций? 1С что ли? При чем тут тогда дотнет?
Ну я часто применяю дот net и в 1С. От этого задачи обмена между различными базами не стала
S>> Там правда нет ссылок, так как ключи в полях.
AVK>Ключи есть а индексов нет?
А зачем индексы для переноса. Они нужны в целевой БД. В том же XML никаких индексов нет.
S>> Это всяко лучше чем текстовые файлы и XML.
AVK>Чем лучше?
Ну вопервых есть описание полей. Для текстов нужно для этого еще файл с описанием полей и кроме одной таблицы в одном файле не передашь. Про XML это объёмы. S>> При этом можно использовать в SQL вместо булков.
AVK>
bulk insert
Можно на основании такой БД, создавать временные таблицы, создавать индексы и применять Merge.
и солнце б утром не вставало, когда бы не было меня
Такая сериализация при определенных условиях будет значительно эффективнее чем XML или JSON.
А когда больше возможностей легче выбрать оптимальный путь решения задачи.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>А XML — набор тегов. Дальше что? S> То есть БД на XML это по твоему нормально?
БД — нет, способ хранения и передачи струтурированных неизменяемых данных — да.
S>>> Смысл такой сериализации когда сериализуется массив. AVK>> Ты сам то понял что сказал? S> Наборы данных. Так пойдет?
Нет. Смысл фразы все равно непонятен.
AVK>>БД для передачи данных между приложениями? Жоско. А как это должно выглядеть? Скидываем граф объектов в БД, потом файл с БД передаем по сети? S> Да а в чем сложность?
Т.е. то, что для передачи типичной посылки в сотню байт придется гонять десятки и сотни килобайт минимальной БД, и на каждую посылку поднимать коннект к новой БД не из пула тебя не пугает, а 30-40% оверхеда по объему и копейки по процессору у XML это ужас-ужас?
S> При этом обмен через MXL с сотнями мегабайт это нормально?
Нормально, если в DOM весь XML не грузить (XMLSerializer, если что, не грузит). А еще лучше через Protobuf или его аналоги.
AVK>>Каких таких конфигураций? 1С что ли? При чем тут тогда дотнет? S> Ну я часто применяю дот net и в 1С. От этого задачи обмена между различными базами не стала
И как ты БД в 1С открывать будешь? Через ADO?
AVK>>Ключи есть а индексов нет? S> А зачем индексы для переноса.
Для переноса — низачем. И БД тоже не нужна.
S>>> Это всяко лучше чем текстовые файлы и XML. AVK>>Чем лучше? S> Ну вопервых есть описание полей.
Какое такое описание полей и чем оно лучше XSD?
S> Для текстов нужно для этого еще файл с описанием полей
Зачем, если формат обмена документирован? Или передавать известные обеим сторонам метаданные в каждой посылке это такой метод эффективного программирования?
S> и кроме одной таблицы в одном файле не передашь.
Это еще почему?
S> Про XML это объёмы.
Еще раз — БД это тоже объемы, потому что БД под совершенно другой сценарий заточены.
S>>> При этом можно использовать в SQL вместо булков. AVK>> S>bulk insert
Что с ним?
S> Можно на основании такой БД, создавать временные таблицы, создавать индексы и применять Merge.
Зачем?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>А XML — набор тегов. Дальше что? S>> То есть БД на XML это по твоему нормально?
AVK>БД — нет, способ хранения и передачи струтурированных неизменяемых данных — да.
S>>>> Смысл такой сериализации когда сериализуется массив. AVK>>> Ты сам то понял что сказал? S>> Наборы данных. Так пойдет?
AVK>Нет. Смысл фразы все равно непонятен.
Например Запрос или результат линка.
AVK>>>БД для передачи данных между приложениями? Жоско. А как это должно выглядеть? Скидываем граф объектов в БД, потом файл с БД передаем по сети? S>> Да а в чем сложность?
AVK>Т.е. то, что для передачи типичной посылки в сотню байт придется гонять десятки и сотни килобайт минимальной БД, и на каждую посылку поднимать коннект к новой БД не из пула тебя не пугает, а 30-40% оверхеда по объему и копейки по процессору у XML это ужас-ужас?
Моя минимальная БД будет занимать не намного места. Размер страницы может варьироваться. Да и предначзначена такая БД не для передачи 2 трех строк. А например тысяч.
S>> При этом обмен через MXL с сотнями мегабайт это нормально?
AVK>Нормально, если в DOM весь XML не грузить (XMLSerializer, если что, не грузит). А еще лучше через Protobuf или его аналоги.
А зачем лишние мегабайты таскать?
AVK>>>Каких таких конфигураций? 1С что ли? При чем тут тогда дотнет? S>> Ну я часто применяю дот net и в 1С. От этого задачи обмена между различными базами не стала
AVK>И как ты БД в 1С открывать будешь? Через ADO?
Да. в 7.7 есть удобный инструмент 1C++, в восьмерке есть встроенная функция описания полей. Я использовал для обновления прайсов в регистрах сведений. А прайсы по запчастям на 4 миллиона записей нормальное явление. AVK>>>Ключи есть а индексов нет? S>> А зачем индексы для переноса.
AVK>Для переноса — низачем. И БД тоже не нужна.
Это тве личное мнение. Если сжать XML то он жмется раз в 10. Размер такой БД будет меньше еще раз в 100. S>>>> Это всяко лучше чем текстовые файлы и XML. AVK>>>Чем лучше? S>> Ну вопервых есть описание полей.
AVK>Какое такое описание полей и чем оно лучше XSD?
Оно не лучше, оно берет лучшее из XML и бинарной сериализацией.
А тем что например такая структура
В таблице будет занимать намного меньше места. Кроме того проще управлять S>> Для текстов нужно для этого еще файл с описанием полей
AVK>Зачем, если формат обмена документирован? Или передавать известные обеим сторонам метаданные в каждой посылке это такой метод эффективного программирования?
S>> и кроме одной таблицы в одном файле не передашь.
AVK>Это еще почему?
S>> Про XML это объёмы.
AVK>Еще раз — БД это тоже объемы, потому что БД под совершенно другой сценарий заточены.
S>>>> При этом можно использовать в SQL вместо булков. AVK>>> S>>bulk insert
AVK>Что с ним?
S>> Можно на основании такой БД, создавать временные таблицы, создавать индексы и применять Merge.
AVK>Зачем?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Такая сериализация при определенных условиях будет значительно эффективнее чем XML или JSON.
AVK>При каких условиях?
При количестве записей в таблицах больше 10.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Такая сериализация при определенных условиях будет значительно эффективнее чем XML или JSON.
AVK>При каких условиях?
Например в нормальной БД данные хранятся в страницах. Излишки могут занимать много места когда небольшой объем данных. Если же сначала сериализовать в List а затем зная размер для каждой таблицы можно просто выделить место в файле. Или перезаписывать в такое хранилище при большом количестве пустого места.
При этом не будет никаких лишних мест. И будет занимать меньше места даже при малых объемах.
Это будет структурированное IStorage.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>>> Смысл такой сериализации когда сериализуется массив. AVK>>>> Ты сам то понял что сказал? S>>> Наборы данных. Так пойдет? AVK>>Нет. Смысл фразы все равно непонятен. S> Например Запрос или результат линка.
Ты не пьян, случаем?
AVK>>Т.е. то, что для передачи типичной посылки в сотню байт придется гонять десятки и сотни килобайт минимальной БД, и на каждую посылку поднимать коннект к новой БД не из пула тебя не пугает, а 30-40% оверхеда по объему и копейки по процессору у XML это ужас-ужас? S> Моя минимальная БД
То есть предлагается еще и спецБД написать?
S>Да и предначзначена такая БД не для передачи 2 трех строк. А например тысяч.
Ну и как будет это выглядеть? Если строк меньше 1000 — передаем одним способом, а если больше — другим?
AVK>>Нормально, если в DOM весь XML не грузить (XMLSerializer, если что, не грузит). А еще лучше через Protobuf или его аналоги. S> А зачем лишние мегабайты таскать?
Нет никаких лишних мегабайтов, особенно во втором случае.
AVK>>И как ты БД в 1С открывать будешь? Через ADO? S> Да.
И этот человек плачется про оверхед XML. Пока ты через ADO будешь БД открывать, даже тормозной Remoting/SOAP успеет раз десять туда/сюда передать данные.
AVK>>Для переноса — низачем. И БД тоже не нужна. S> Это тве личное мнение.
А у тебя, надо думать, общепринятая точка зрения? Почему тогда бред, который ты описываешь, в природе не встречается, зато ужас-ужас ака ХМЛ — сплошь и рядом?
S> Если сжать XML то он жмется раз в 10.
В 10 не жмется. Сжать, опять же, никто не мешает без всяких БД.
S> Размер такой БД будет меньше еще раз в 100.
А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь.
AVK>>Какое такое описание полей и чем оно лучше XSD? S>Оно не лучше
Тогда и твоя мегаидея не лучше.
S>, оно берет лучшее из XML и бинарной сериализацией.
Что именно?
S> А тем что например такая структура
S><CatalogObject.Контрагенты> S> <IsFolder>true</IsFolder> S> <Ref>2eca11b5-f2d4-46e4-8b86-5d4579c64a64</Ref> S> <DeletionMark>false</DeletionMark> S> <Parent>00000000-0000-0000-0000-000000000000</Parent> S> <Code>000016 </Code> S> <Description>ПОСТАВЩИКИ</Description> S> <Комментарий/> S> </CatalogObject.Контрагенты> S>В таблице будет занимать намного меньше места.
А в формате Protobuf?
S> Кроме того проще управлять
Чем проще?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, Serginio1, Вы писали:
S> Например в нормальной БД данные хранятся в страницах.
Ага. И fill factor обычно используется равным 0.5. Это означает, что избыточность минимум в два раза. На любом объеме данных.
S>Если же сначала сериализовать в List а затем зная размер для каждой таблицы можно просто выделить место в файле.
И зачем тут БД?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>>>>> Смысл такой сериализации когда сериализуется массив. AVK>>>>> Ты сам то понял что сказал? S>>>> Наборы данных. Так пойдет? AVK>>>Нет. Смысл фразы все равно непонятен. S>> Например Запрос или результат линка.
AVK>Ты не пьян, случаем?
Уже 6 лет не пью и фитнесом занимаюсь. AVK>>>Т.е. то, что для передачи типичной посылки в сотню байт придется гонять десятки и сотни килобайт минимальной БД, и на каждую посылку поднимать коннект к новой БД не из пула тебя не пугает, а 30-40% оверхеда по объему и копейки по процессору у XML это ужас-ужас? S>> Моя минимальная БД
AVK>То есть предлагается еще и спецБД написать?
А чего её писать то. Там все элементарно. S>>Да и предначзначена такая БД не для передачи 2 трех строк. А например тысяч.
AVK>Ну и как будет это выглядеть? Если строк меньше 1000 — передаем одним способом, а если больше — другим?
Я в предыдущей ветке писал, как можно отказавшиь от страниц, записать таблицу в стрим без лишнего места.
AVK>>>Нормально, если в DOM весь XML не грузить (XMLSerializer, если что, не грузит). А еще лучше через Protobuf или его аналоги. S>> А зачем лишние мегабайты таскать?
AVK>Нет никаких лишних мегабайтов, особенно во втором случае.
Кстати а как данные Protobuf хранит? AVK>>>И как ты БД в 1С открывать будешь? Через ADO? S>> Да.
AVK>И этот человек плачется про оверхед XML. Пока ты через ADO будешь БД открывать, даже тормозной Remoting/SOAP успеет раз десять туда/сюда передать данные.
У меня другие объемы данных. Например обновить 4 миллиона записей меньше 2 минут занимает.
AVK>>>Для переноса — низачем. И БД тоже не нужна. S>> Это тве личное мнение.
AVK>А у тебя, надо думать, общепринятая точка зрения? Почему тогда бред, который ты описываешь, в природе не встречается, зато ужас-ужас ака ХМЛ — сплошь и рядом?
А тем, что нет других механизмов. Вот например появился Protobuf будут его использовать. S>> Если сжать XML то он жмется раз в 10.
AVK>В 10 не жмется. Сжать, опять же, никто не мешает без всяких БД.
S>> Размер такой БД будет меньше еще раз в 100.
AVK>А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь.
Я это проделывал многократно. Пример тому можно посмотреть как увеличится БД. Да и просто посчитать реальный объем данных в БД несложно.
AVK>>>Какое такое описание полей и чем оно лучше XSD? S>>Оно не лучше
AVK>Тогда и твоя мегаидея не лучше.
S>>, оно берет лучшее из XML и бинарной сериализацией.
AVK>Что именно?
S>> А тем что например такая структура
S>><CatalogObject.Контрагенты> S>> <IsFolder>true</IsFolder> S>> <Ref>2eca11b5-f2d4-46e4-8b86-5d4579c64a64</Ref> S>> <DeletionMark>false</DeletionMark> S>> <Parent>00000000-0000-0000-0000-000000000000</Parent> S>> <Code>000016 </Code> S>> <Description>ПОСТАВЩИКИ</Description> S>> <Комментарий/> S>> </CatalogObject.Контрагенты> S>>В таблице будет занимать намного меньше места.
AVK>А в формате Protobuf?
А можешь привести этот формат? S>> Кроме того проще управлять
AVK>Чем проще?
Вот я например не нашел описания хранения данных Protobuf. А вот например пользоваться Access знают все. БД в простейшем случае это набор таблиц зранящих записи в виде структур.
Исключения составляют Блоб таблицы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> Например в нормальной БД данные хранятся в страницах.
AVK>Ага. И fill factor обычно используется равным 0.5. Это означает, что избыточность минимум в два раза. На любом объеме данных.
S>>Если же сначала сериализовать в List а затем зная размер для каждой таблицы можно просто выделить место в файле.
AVK>И зачем тут БД?
Еще раз БД это набор таблиц. Называй это как хочешь. Каждый тип хранится в своей таблице. Типы имеющие потомки хранятся в виде структуры тип (номер таблицы) и номер записи в таблице.
Как по твоему должно называться такое хранилище?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>То есть предлагается еще и спецБД написать? S> А чего её писать то. Там все элементарно.
AVK>>Ну и как будет это выглядеть? Если строк меньше 1000 — передаем одним способом, а если больше — другим? S> Я в предыдущей ветке писал, как можно отказавшиь от страниц, записать таблицу в стрим без лишнего места.
Ну то есть там и БД не БД. И чем это отличается от Protobuf?
AVK>>Нет никаких лишних мегабайтов, особенно во втором случае. S> Кстати а как данные Protobuf хранит?
http://en.wikipedia.org/wiki/Protocol_Buffers и далее по ссылкам.
AVK>>А у тебя, надо думать, общепринятая точка зрения? Почему тогда бред, который ты описываешь, в природе не встречается, зато ужас-ужас ака ХМЛ — сплошь и рядом? S> А тем, что нет других механизмов.
А почему их нет? Неужели потому что никому твоя гениальная идея не пришла на ум?
S> Вот например появился Protobuf будут его использовать.
Он давно появился. Но это ж не БД!
AVK>>А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь. S> Я это проделывал многократно.
И какую БД ты использовал для передачи данных?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, Serginio1, Вы писали:
AVK>>И зачем тут БД? S> Еще раз БД это набор таблиц.
A database is an organized collection of data. The data is typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies).
Ключевой момент я выделил жирным.
S> Называй это как хочешь.
Что "это"?
S> Каждый тип хранится в своей таблице.
А что такое таблица?
S>Как по твоему должно называться такое хранилище?
Просто структурированное хранилище.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>>>А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь. S>> Я это проделывал многократно.
AVK>И какую БД ты использовал для передачи данных? http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=2019
исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>И зачем тут БД? S>> Еще раз БД это набор таблиц.
AVK>
AVK>A database is an organized collection of data. The data is typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies).
AVK>Ключевой момент я выделил жирным.
S>> Называй это как хочешь.
AVK>Что "это"?
S>> Каждый тип хранится в своей таблице.
AVK>А что такое таблица?
Ну можно представить в виде IList<T>
S>>Как по твоему должно называться такое хранилище?
AVK>Просто структурированное хранилище.
Хорошо, так чем плохо структурированное хранилище для целей сериализации?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
AVK>И чем это лучше того же http://ravendb.net/ ?
Да ничем. Просто такое структурированное хранилище прекрасно подходит для целей сериализации, занимая минимальное количество кода, а значит может быть встроено в системные сборки. На дженериках это хранилище вообще пишется на раз.
Кстати спасибо за ссылки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
AVK>И чем это лучше того же http://ravendb.net/ ? http://ravendb.net/docs/intro/ravendb-in-a-nutshell
Данные в RavenDB хранится без схемы как документы JSON
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Просто структурированное хранилище. S> Хорошо, так чем плохо структурированное хранилище для целей сериализации?
Хранилище? Наверное тем, что спроектировано для хранения, а не для передачи данных.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
_>>Ты забыл ещё JSON! Их тоже вроде 2-3 штуки!!! публичных должно быть, сам видел AVK>Я не забыл. Во-первых в самом фреймворке их вроде нет (MVC вроде сейчас как то отдельно), во-вторых это текстовый формат.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>При каких условиях? S>> При количестве записей в таблицах больше 10.
AVK>Откуда взята эта цифра?
Нужны затраты на описание полей, размещение таблиц. В среднем в классе около 10 полей. То есть занимаемый размер 10 записей в таком хранилище будет около 10 записей с помощью BF
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>И чем это лучше того же http://ravendb.net/ ? S>> Да ничем.
AVK>Значит велосипед.
Ну с этой точки зрения любая программа это велосипед. Опять же я говорю о Структурированном хранилище для сериализации и десериализации.
Опять же написать её не проблема в NET через рефлекшн. S>> Просто такое структурированное хранилище прекрасно подходит для целей сериализации
AVK>Так бери да пользуйся, меппер классов на рейвен идет в комплекте, embedded версия вроде тоже была.
А толку? Для себя я могу сделать что угодно. Но вот работаю то я не сам с собой. А отгадай какой самый часто встречаемый формат для обмена данных? Ну конечно ёксель.
Затем идут текстовые файлы (CSV), вэб сервисы (XML).
А вот совместное использование возможно только тогда когда такой механизм будет открытым и встроенным в системные сборки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Просто структурированное хранилище. S>> Хорошо, так чем плохо структурированное хранилище для целей сериализации?
AVK>Хранилище? Наверное тем, что спроектировано для хранения, а не для передачи данных.
Что бы передать данные ты должен сохранить в поток. Поток это тоже хранилище только не структурированное.
и солнце б утром не вставало, когда бы не было меня
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Так и такое есть. S>> Почему тогда такой сериализации нет вместе с XML и Бинарной?
AVK>А зачем вместе с XML и бинарной?
Например для того, что бы не изобретать велосипеды http://rsdn.ru/forum/dotnet/244451.flat
При этом по скорости предложенная мною сериализация будет еще быстрее, так как Table это массив массивов, которые для примитивных типов записываются в поток на раз. Даже с учетом того, что размер капасити Табле больше чем размер реальных данных. Но это сериализация в лоб. Для Table можно учитывать это обстоятельство и делать для него специально заточенныей сериализатор.
и солнце б утром не вставало, когда бы не было меня
