fshp, имхо любой сразу подсядет на это дело если его посадить за ide и дать потыкать хорошо продуманную библиотеку. Возможность не заглядывая в доки использовать класс, ориентируясь на принимаемые/возвращаемые значения и имена методов очень подкупает.
mitaichik, я тут воткнулся в кусок кода. Я понимаю что он делает, правда, но хотел докапацо до сути. Вызываем функцию ей передаем объект а в объекте объявляем анонимную функцию в которой одним из параметров колбек и этот колбек потом в теле вызываем. Все IDE бесполезна. Ладно, идет ручками в сорцы а там еще интересней, utils.inherits и часть методов вызывается через события. Привет номер два) И доки тут не помогут.
VitalyT: теперь понятно. Честно говоря все это к сожалению не очень интересно, поскольку уровень задач требует своей или готовой ORM в том или ином виде.
Если не ORM, то какие либо инструменты длля общения с бд мне не нужны, тут я быстренько накидываю свое, удобное, ибо почти у всех как вы говорите много недостатков, начиная с того, что мне каждый раз нужно лезть внутрь, вырывать всю эмуляцию параметров и переводить инструмент на использование реальных кешируемых параметризованных запросов.
Сергей Протько: Даже если в один поток то это не критично при нормальной оптимизации.
ЗЫ Кстати а почему однопоточный? В исходники не смотрел но даже сомнения не закралось. Отловили пакет отдали в нужнию функцию и дальше себе цикл гоняем.
Вы мой моск теперь совсем порвали. Технологическая сингулярность в действии. Даже для ноды фулл стек выбрать можно только наугад.
Видимо в таких условиях скоро выгодней будет каждый раз писать свое...
Ниже уже озвучили основные тезисы. Еще добавлю что самый простой способ это репликация бд, если падает связать с сервером переключаетесь на локальную бд и переходите в режим чтения. как правило нет требования 100%го онлайна, есть требование доступа к данным.
Хотя если есть возможность потратить N времени на разработку меанизма слияния, включающего решение конфликтов то дело хорошее.
о, хороший список, надо глянуть. Вопрос в том что найти ответ на вопрос что же лучше из всего длинного списк адля создания real-time web-based application мне не удалось
чем же интересней если не секрет?
Готовые решения, тонны документации, JVM это плюсы, а вот минусов объективно назвать не могу. Это хреновый аргумент в споре)
Это все конечно неплохо. Но для этих целей не достаточно ли одного Pg-native? Смысл то как раз в том, что множественные связи сложных объектов вынуждают меня либо воспользоваться ORM(ну или свою слепить) либо тратить время на тщательное обдумывание загрузки коллекции объектов и менеджмента этих самых коллекций.
ЗЫ нигде у вас не нашел описание работы с байт-типами а так же именованных prepared
Vitaly Sivkov: это я читал. Видимо ему драйвер придецо подмахивать. Есть желание заставить его использовать реальный postgresql prepare ибо это даст существенный выигрыш
