Вышел Compiere 2.4.4c

А кто-нить его реально пробовал в действии? У меня Оракла вот нет, а поддержка Постгрес там пока в никакой практически стадии. КТО ПРОБОВАЛ? ;) Рассказывайте.

а при чем тут linux -- compier'у разве есть дело на какой ос работать?

Да, мне тоже интересно как она. Даже пусть с ораклом! Такое впечатление что это самое продвинутое из опенсорса в плане ERP/CRM.

глюкалово доморощенное и кривоногое этот Компьер

Весьма продвинутая вещь, покруче даже некоторых комерческих продуктов будет. А Оракл они высылают посмотри на форуме.

http://compiere.ru/forum/viewtopic.php?t=4

2 Вячеслав

Здравствуйте. :))

Если вы заглянете в эту ветку, то могли бы рассказать общественности как обстоят дела с переносом Compiere на JBoss и вытекающей из этого независимостью от базы данных? Oracle, IMHO, многих останавливает.

Всех благ и успехов. :))

>>Compiere на JBoss и вытекающей из этого независимостью от базы данных?

А..У,..Э...

а из чего это собствеено вытекает???

почитай хотя бы

http://www.compiere.org/technology/pg/index.html

и прослезись о "независимости" от фичь базы...

2 ifconfig

возвращаю Ваш портрет - http://www.compiere.org/technology/independence.html :)))

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

Поделились бы результами хмм.. исследования. :))

Про независимость Compiere от БД. Забудьте про портирование на Postgress, это решение уже устарело и отвергнуто. Принято решение переходить на JBoss, после этого система сможет работать на всех базах, что поддерживаются JBoss, а это все самые известные коммерческие и бесплатные БД.

Проблема одна - подобный переход не простое техническое решение и он займет много времени, точных данных о сроках завершения перехода на JBoss у меня нет (да и я вообще не уверен, что есть подобный точный план), но я лично расчитываю увидеть первую JBoss версию не ранее, чем через 6-8 месяцев. :( Одно могу сказать точно, интерес к переходу на JBoss проявляет огромное количество людей (не только в России), поэтому (по словам самого автора системы) он сейчас вплотную занимается этой проблемой.

Все желающие пообщаться на эту тему приглашаются на сайт в форум http://www.compiere.ru/forum

Вячеслав Педак

>>я знаю не так давно и может и сейчас продолжаете сравнение Oracle & PostgreSQL.

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

>>Принято решение переходить на JBoss, после этого система сможет работать на всех базах, что поддерживаются JBoss, а это все самые известные коммерческие и бесплатные БД.

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


>>Проблема одна - подобный переход не простое техническое решение и он займет много времени,

угу.. что собно и понятно.. ибо все основные фичи конкретных баз, ну хотя бы работу с датами, прийдеться реализовывать на стороне AS. Хотя это простенький пример, но отражает "изобретение велосипеда" на фоне всеобщей портабельности с "любой субд"...

И еще важный вывод их этого... авторы косвено подтвердили факт, что писать под oracle элементарно быстрее...


P.S. кстати, я смотрел структуру базы у сабжа... беглым взлядом не заметил сильной привязки к Ораклу... так что все может быть. Может и портанут в разумном скором будущем..Чему я буду рад только...

А никто и не говорит, что будет использоваться SQL92. Есть СТАНДАРТНЫЕ возможности в рамках технологии J2EE (в частности CMP Entity Beans), которые позволяют не привязываться к конкретной БД, всю работу с БД берет на себя сервер приложений. Если интересно как именно это делается, то можно немного почитать здесь http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/CMP.html

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

А писать под Oracle не быстрее, этот факт никто не подтверждал, почему же был выбран Oracle я уже писал в форуме http://compiere.ru/forum/viewtopic.php?t=3

Вячеслав Педак

>>А никто и не говорит, что будет использоваться SQL92
извините, а зачем тогда RDBMS нужна вообще??

>>Есть СТАНДАРТНЫЕ возможности в рамках технологии J2EE (в частности CMP Entity Beans)

спасибо, разумееться я знаю и использую этот подход тогда, когда , на мой взляд, он оправдан.

>>А писать под Oracle не быстрее
вопрос снова спорный, мне трудно аргументировать, но опыт показывает именно это %(
Не надо делать сложным, то что проще простого. Опять же тривиальный пример, если работа с датами давным давно придумана и отлажена, то хранить в базе unix time а в AS изобретать (причем каждый разработчик свое) классы для преобразований даты всеже хоть и не сложнее, но элементарно дольше.. Да и что бы вы там не говорили, скорость работы этого ниже...
Пример второй, контекстные поиски в документах хранимых в базе.. К примеру в вордовских файлах.

Так что кесарю кесарево... Разумное сочетание AS + RDBMS всеже более предпочтительный вариант..


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

Хотя отказ от очень недешевого Оракла будет большим ГУД.... за это пожалуй и можно платить и скоростью разработки и скоростью самой системы.. Хотя данный подход врядли будет характеризовать данный проект как привлекательный для крупных комерческих предприятий..

>>>>А никто и не говорит, что будет использоваться SQL92 >>извините, а зачем тогда RDBMS нужна вообще??

С имел в виду, что будет использоваться расширенный синтаксис SQL (для каждой базы свой), а те только то, что в SQL92

У меня складывается впечатление, что вы совсем не знакомы с теми технологиями о чем речь (в этом нет ничего плохого, так как это специфичные для java технологии). Дело в том, что там нет никаких подобных проблем с датами. Ничего изобретать разработчику не надо, а надо пользоваться стандартными классами (которые уже умеют делать все что надо).

Пр чем же здесь контектсный поиск в документах? В Compiere этого нет, да и это совсем не сложно организовать.

ИМНО Скорость разработки в основном зависит от опыта команды (в используемых технологиях).

А почему так долго будет портироваться, дак только потому, что все основная разработка в Compiere сосредоточена в руках одного человека (автора системы). Да это плохо, и почему он не хочет это менять я тоже не знаю. Но пока он удовлетворяет все основные запросы и "держит руку на пульсе". Если ситуация изменится, то думаю появится параллельная ветка поддерживаемая другими (слишком уж много народа уже вовлечено в это)