Миграционный Firebird релиз на основе официальной версии 1.5.2.4731

Муйня какая-то ИМХО. Что там "вытаскивать"? Что "разрабатывать"? Firebird 1 - это и есть InterBase 6 с исправленными глюками, соответственно переносимость при прямых руках - 100%. ИМХО кое-кто просто хочет заработать бабла из воздуха, только и всего.

anonymous
(04.02.06 12:34:53 MSK)

Ответ на: комментарий от anonymous 04.02.06 12:34:53 MSK

ИМХО вы мало знаете о различиях в Interbase и FireBird.

Да и проект сей предназначен для тех, кто не хочет посвящать полгода жизни изучению различий и миграции.

anonymous
(04.02.06 13:57:22 MSK)

> показало среднее увеличение производительности существующих проектов более чем в 5 раз

Ага. За счет воздействия торсионных полей на исходники.

anonymous
(04.02.06 14:00:19 MSK)

Ответ на: комментарий от anonymous 04.02.06 13:57:22 MSK

> ИМХО вы мало знаете о различиях в Interbase и FireBird.

Вы знаете больше? Так поведайте миру, не таитесь! И чем же таким страшным отличается FB 1 от IB 6?

anonymous
(04.02.06 14:43:51 MSK)

Ссылка

А какие проблемы с миграцией ? ... backup/restore с перескоком на более высокие версии ...

I_one ★
(04.02.06 15:28:52 MSK)

Ответ на: комментарий от I_one 04.02.06 15:28:52 MSK

Приведу один из примеров, которые устранили: В каст-операциях преобразования чисел с двойной точностью в IB например число 2.5 преобразуется как "2.5", а в FB как "2.500000000000000". Таким образом имея самую простейшую операцию CAST( 2.5 as double) || '%' в разных СУБД будет выдавать разные результаты. В IB например вернется "2.5%", в FB будет "2.5000000000000000%", ну а если мы имеем процедуру в СУБД, возвращающую этот результат через например VARCHAR(15), то в результате процедура работать не будет после переноса базы данных с одной версии (поскольку длина возвращаемого результата в IB будет в этом примере 4 символа, а в FB - 19. 19 если кто не в курсе (ананимусам) - больше 15 и имеем переполнение ( или исключение ) и СУБД отвалится со всей внутренней математикой ). Это я описал только одно изменение которое мы внесли чтобы устранить эту проблему, и таких ситуаций там немало. Большой привет ананимусам, оценившим нашу работу.

OpenStorm ★★★
(04.02.06 18:32:17 MSK) автор топика

Ответ на: комментарий от anonymous 04.02.06 14:00:19 MSK

>> показало среднее увеличение производительности существующих проектов более чем в 5 раз

>Ага. За счет воздействия торсионных полей на исходники.

нет, за счет того что например версий IB 5.6 Класик, поддерживающих многоядерные процессорные архитектуры не существует в природе и ей ты хоть 10 процессоров поставь, быстрее СУБД работать не будет. Второе - включаяется NPTL если ты в курсе что это такое, третье - разница в СУБД IB (5.6... 6.0) и FB уже колосальная...

OpenStorm ★★★
(04.02.06 18:43:04 MSK) автор топика

Ссылка

Ответ на: комментарий от OpenStorm 04.02.06 18:32:17 MSK

Не все ананимусы одинаковы.
OpenStorm - респект!

anonymous
(04.02.06 18:53:23 MSK)

Ссылка

Ответ на: комментарий от OpenStorm 04.02.06 18:32:17 MSK

Во-первых не "double", а "double precision";

Во-вторых именно как для _явного_ double precision разница между 2.5 и 2.500000000000000 не понятна ни разу. И то и другое - число.

В третьих прокастить к даблу, а потом конкатенировать со строкой (и даже просто конкатенировать дабл со строкой) - это умудриться надо. Тут не сервер надо править, а руки программисту;

В четвертых насколько я понимаю, поведение FB в этой части соответствует (пусть и не до конца) стандарту ANSI SQL 92, то есть, реализуя в FB поведение IB вы фактически совершаете downgrade до нестандартной версии. Тут и не пахнет никакой "migration" - вы просто вводите пользователя в заблуждение;

Наконец в пятых, по поводу исключений и "отваливающихся" (черт знает что вы под этим имели в виду) баз данных. К сожалению не могу проверить на IB6, но предлагаю это сделать вам. Подсуньте вот эту процедурку одному из облагодетельствованых вами клиентов. Если IB6 работает именно так, как я предполагаю, то мы все вместе дружно посмеемся.

CREATE PROCEDURE TEST RETURNS ( VC VARCHAR(15)) AS BEGIN SELECT CAST(2/3 AS DOUBLE PRECISION) || '%' FROM RDB$DATABASE INTO VC; SUSPEND; END

anonymous
(04.02.06 21:48:32 MSK)

Ответ на: комментарий от anonymous 04.02.06 21:48:32 MSK

Пардон, TeX поломал текст процедуры. 

CREATE PROCEDURE TEST
RETURNS (
  VC VARCHAR(15)
)
AS
BEGIN
  SELECT CAST(2/6 AS DOUBLE PRECISION) || '%' FROM RDB$DATABASE INTO VC;
  SUSPEND;
END

anonymous
(04.02.06 21:51:05 MSK)

Ответ на: комментарий от anonymous 04.02.06 21:51:05 MSK

2/6 = 1/3 = 0.3333333(3)... - в этом случае поведение будет одинаково во всех версиях (неудачный пример), ибо значащие значения будут во всех версиях IB & FB. Совершенно верно, в том числе именно даунгрейд для вытягивания старых проектов на IB в FB текущей версии мы и сделали. Новые проекты на нашем FB(MR) работать будут, старые (чего и добивались) - тоже.

OpenStorm ★★★
(04.02.06 23:46:02 MSK) автор топика

Ответ на: комментарий от anonymous 04.02.06 21:51:05 MSK

Между строками результатов КАСТ "18%" (IB) и "18.000000000000000%"(FB) есть разница. Ну а про руки программистов можно долго разговаривать и действительно было не все идеально. IB проекты были не наши, мы их только выдернули с виндовых IB серверов на нормальные платформы где можно будет их развивать и подправлять без остановки бизнес-процессов предприятия.

OpenStorm ★★★
(05.02.06 00:06:30 MSK) автор топика

Ответ на: комментарий от OpenStorm 05.02.06 00:06:30 MSK

Лучьше бы сделали нормальную многопоточность в superserver, а так ваша работа никому не нужна ... подумаешь выдернули базы из виндовых серверов ... кстати ещё одно из направлений куда стоило бы копать: приведение к стандарту sql99, а также возможноть нормальной самостоятельной сборки на различных *nix платформах ... пердеть в лужу не стоит ... тем более что есть на что ориентироватся ...

I_one ★
(05.02.06 04:12:35 MSK)

Ссылка

Грубо говоря, решение для ленивых или для закрытых сорцов. Если свою кривизну выпрямлять не хочется или не можется. Эдакий эмулятор глюков IB на фоне производительности FB. Безусловно, решение найдет покупателя. Хотя не совсем понятно, как авторы собираются поступать с изменениями, нарушающими совместимость, но при этом исправляющими серьезные ошибки. Или оная совместимость превыше неверных результатов и порчи базы?

anonymous
(05.02.06 09:39:47 MSK)

Ссылка

Ответ на: комментарий от anonymous 04.02.06 21:48:32 MSK

>>В третьих прокастить к даблу, а потом конкатенировать со строкой (и даже просто конкатенировать дабл со строкой) - это умудриться надо. Тут не сервер надо править, а руки программисту;

Прямые руки разработчика в контракте не предусмотрены, в отличие от условий эксплуатации поделия. Последние в этом случае явно нарушаются. У вас 2 варианта, вылизать купленное самому, либо держать старый и новый сервер. Один для работы, второй для понтов.

anonymous
(06.02.06 11:49:47 MSK)

Ссылка

Ответ на: комментарий от OpenStorm 04.02.06 23:46:02 MSK

> 2/6 = 1/3 = 0.3333333(3)... - в этом случае поведение будет одинаково во всех версиях

Именно! То есть сперва было найдено синтетическое "расхождение", якобы приводящее к глюкам и "отваливанию" базы (кстати вы так и не рассказали что это такое). А потом была сделана заплатка, приводящая поведение FB, ведущего себя одинаково _во всех случаях_ к поведению IB, которое зависит от того, какие числа ему подсунули. И все это было названо гордым именем "миграционный релиз". :(

> Совершенно верно, в том числе именно даунгрейд для вытягивания старых проектов на IB в FB текущей версии мы и сделали

То есть для _создания видимости_ того, что проекты могут работать на FB текущей версии? И вот за это - вы хотите денег?! Мда-а-а-а...

> Новые проекты на нашем FB(MR) работать будут,

Серьезно? Даже те, в которых авторы жестко положились на cast(2.5 as double precision) == 2.500000000000? Не морочьте людям голову.

> старые (чего и добивались) - тоже.

Угу, ровно до того момента, пока наивный пользователь, считающий, что он совершил миграцию на Firebird не захочет поставить себе полноценный FB 1.5.3. После чего огребет совершенно те же сюрпризы, от которых вы его якобы так тщательно застраховали.

anonymous
(06.02.06 12:32:24 MSK)

Ответ на: комментарий от anonymous 06.02.06 12:32:24 MSK

>Именно! То есть сперва было найдено синтетическое "расхождение", якобы приводящее к глюкам и "отваливанию" базы (кстати вы так и не рассказали что это такое). А потом была сделана заплатка, приводящая поведение FB, ведущего себя одинаково _во всех случаях_ к поведению IB, которое зависит от того, какие числа ему подсунули. И все это было названо гордым именем "миграционный релиз". :(

С точностью до наоборот.

>То есть для _создания видимости_ того, что проекты могут работать на FB текущей версии? И вот за это - вы хотите денег?! Мда-а-а-а...

Не создания видимости, а для работы старых IB проектов на FB. Какие деньги... .?!

>Серьезно? Даже те, в которых авторы жестко положились на cast(2.5 as double precision) == 2.500000000000? Не морочьте людям голову.

Вы бредите. Поставьте FB 1.5.x для Windows и для Linux и узрите эту разницу на одной и той же версии :))). Разница появляется из-за разницы при сборке STDLIB в Linux(unix) & Windows ( т.е. на различных платформах ). И кончайте заявления по поводу ANSI SQL 92, ANSI SQL 99 и не вводите в заблуждение других что это такое если сами не понимаете, так как там эти требования там абсолютно не прописаны и они касаются только SQL.

> Угу, ровно до того момента, пока наивный пользователь, считающий, что он совершил миграцию на Firebird не захочет поставить себе полноценный FB 1.5.3. После чего огребет совершенно те же сюрпризы, от которых вы его якобы так тщательно застраховали.

Мы не страховая компания и не продаем свое решение.

и еще раз насчет:
> ....То есть для _создания видимости_ того, что проекты могут работать на FB текущей версии? И вот за это - ^^^вы хотите денег?!^^^Мда-а-а-а...

повторю последний раз для особо ... (сори) т-у-п-ы-х: - результаты мы выложили абсолютно СВО-БО-ДНО... Вас никто не заставляет использовать наше решение, платить нам, но судя по количеству загрузок интерес у нашей разработки имеется и мы рады помочь еще раз повторяю "безвозмездно" тем, кто столкнется с такой же проблемой как и мы.

OpenStorm ★★★
(06.02.06 13:24:45 MSK) автор топика

Ответ на: комментарий от OpenStorm 06.02.06 13:24:45 MSK

> С точностью до наоборот.

Что именно "наоборот"? Разрядность ответа в IB не зависит от количества значащих цифр? Разрядность FB зависит? Вы только что сами демонстрировали обратное. Расхождение не является "синтетическим"? Однако тезис о том, что написать его можно либо умышленно либо кривыми руками вы не отрицали.

> Не создания видимости, а для работы старых IB проектов на FB.

Не на FB, а на вашей поделке. В этом вся суть: на _настоящем_ FB подобные проекты как не работали, так и не будут.

>> Серьезно? Даже те, в которых авторы жестко положились на cast(2.5 as double precision) == 2.500000000000? Не морочьте людям голову. > Разница появляется из-за разницы при сборке STDLIB в Linux(unix) & Windows

Какие к черту разные платформы, о чем вы? У вас есть два проекта, в одном автор посчитал, что cast(2.5 as double precision) = 2.5, а в другом - что 2.500000000000. Как вы собираетесь заставить работать _ОБА_ этих проекта на вашем изделии (т.е. _физически_ на одном сервере)? К чему эти разговоры про "работает и старое и новое"? К чему сказки про какую-то "миграцию"?

> И кончайте заявления по поводу ANSI SQL 92, ANSI SQL 99 и не вводите в заблуждение других что это такое если сами не понимаете, так как там эти требования там абсолютно не прописаны и они касаются только SQL.

Покурите на досуге эти стандарты и вкурите, что преобразование типов (в том числе и CAST числовых типов к строкам) там прописан более чем подробно.

> повторю последний раз для особо ... (сори) т-у-п-ы-х: - результаты мы выложили абсолютно СВО-БО-ДНО...

Объясняю еще раз для особо (сори) п-р-е-м-у-д-р-ы-х: вы пудрите людям мозги, называя downgrade миграцией. То, что вы не просите за это денег (кстати, поддержка у вас тоже бесплатна?), конечно вас в какой-то мере извиняет, но факт остается фактом: с вашей стороны наличествует самый обыкновенный обман пользователей.

anonymous
(06.02.06 16:30:25 MSK)

Ответ на: комментарий от anonymous 06.02.06 16:30:25 MSK

>oбъясняю еще раз для особо (сори) п-р-е-м-у-д-р-ы-х: вы пудрите людям мозги, называя downgrade миграцией

Мы действительно считаем возможность работы на FB старых проектов, разработанных например под управлением IB 5.6 миграцией, потому что до нас подобного никто не сделал и не запустил безболезненно эти проекты на базе Unix-SMP-NPTL. Если вы покажете нам хоть одну ошибку, спровоцированную нашими изменениями, мы с вами согласимся и исправим. Релиз 1.5.3 мы также отслеживаем и представьте себе что до четверти наших изменений лягло в официальный 1.5.3 (и мы считаем что это довольно много).

>То, что вы не просите за это денег (кстати, поддержка у вас тоже бесплатна?), конечно вас в какой-то мере извиняет,

Нам платят сами заказчики чтобы мы устраняли эти проблемы. В том числе это позволяет существовать компании. Результаты работы мы выложили свободно чтобы комунити показало нам где еще недочеты. Если вы в курсе сколько реальных проектов застряло на старых платформах, то наверное представляете сколько головной боли это доставляет программистам, переписывающих эти системы на новые платформы. Мы посмотрели на эту проблему с другой стороны (со стороны СУБД) и просто научили ее понимать эти проекты. Например имеем 16 проектов под управлением IB 5.6 и СУБД FB 1.5. При переносе все 16 глючат, зато стабильно работает СУБД. Обычно нанимают кучу парней, чтобы переписать эти 16 проектов на новую СУБД. А не проще научить СУБД FB понимать эти старые проекты?

>но факт остается фактом: с вашей стороны наличествует самый обыкновенный обман пользователей.

:))). Такое ощущение что мы наступили на кого-то из конкурентов, переписывающего старые IB проекты на новые платформы.

OpenStorm ★★★
(06.02.06 17:31:27 MSK) автор топика

Ответ на: комментарий от OpenStorm 06.02.06 17:31:27 MSK

> до четверти наших изменений лягло в официальный 1.5.3

Я не знаю, что и куда у вас "лягло", но практически все фиксы в 1.5.3 портированы из 2.0. У вас там своя рука? :-) Дабы не быть голословным, предлагаю озвучить изменения в 1.5.3, внесенные вами.

anonymous
(07.02.06 12:26:49 MSK)

Ответ на: комментарий от OpenStorm 06.02.06 17:31:27 MSK

> Мы действительно считаем возможность работы на FB старых проектов, разработанных например под управлением IB 5.6 миграцией, потому что до нас подобного никто не сделал и не запустил безболезненно эти проекты на базе Unix-SMP-NPTL

А еще до вас никто не пытался надевать носки через голову и плавать в бетономешалке. Никому это просто в голову не приходило, хотя при известной доле ловкости возможно и удалось бы. Однако вопрос не в этом, повторяю: при чем здесь миграция? Откуда и куда мигрируют ваши пользователи?

> Если вы покажете нам хоть одну ошибку, спровоцированную нашими изменениями, мы с вами согласимся и исправим.

Делать мне больше нечего - в вашей поделке ошибки искать. Этим и без меня ваши несчастные пользователи займутся, когда надумают на полноценный FB переходить.

> Релиз 1.5.3 мы также отслеживаем и представьте себе что до четверти наших изменений лягло в официальный 1.5.3

Присоединяюсь к тезке-анонимусу: список того, что "лягло" по вашей указке - в студию.

> Нам платят сами заказчики чтобы мы устраняли эти проблемы.

Надо сказать вы выбрали весьма оригинальный способ решения проблем - симуляцию того, что проблемы отсутствуют. Примерно как лечить детский насморк через зашивание чрева роженице. Нет ребенка - нет проблемы.

> А не проще научить СУБД FB понимать эти старые проекты?

Простота - хуже воровства. Про совместимость с новыми проектами я вам уже говорил, плюс к тому совершенно неизвестно, каких багов вы успели насажать в свое детище и какими глюками это в конечном итоге обернется для пользователей. Но самое веселое их ждет впереди: рано или поздно проект под новый сервер переписывать все равно придется и ваше творение им в этом не поможет ни на йоту. Такая вот любопытная получается "миграция".

> Такое ощущение что мы наступили на кого-то из конкурентов, переписывающего старые IB проекты на новые платформы.

:)) Вы при всем желании не сможете на них наступить, потому как "кучи парней, зарабатывающих переписыванием проектов" только ради переноса их с одной версии сервера на другую существуют исключительно в вашем воображении. Все написаное более-менее прямыми руками - переносится практически без проблем и переделки почти не требует.

anonymous
(07.02.06 13:21:48 MSK)

Ссылка