Стоило озаглавить как «Еще один магазин на Django». Пока непонятно чем он кардинально отличается от Satchmo или Satchless, с учетом того, что команда последнего принимала участие в разработке Оскара.
Без сравнения ИМХО получился пост just FYI. =\
SQLAlchemy — Michael Bayer, претензии можно отрпавить на mike[at]zzzcomputing.com
Django-ORM — Alex Gaynor, Adrian Holovaty и компания. За конкретикой и критикой — на гитхаб.
А если обойтись без класс-маппера? Сделать всё на Table, Column и т.п? Чувствую, что оверхеда должно быть меньше, т.к. маппер притягивает метакласс для обработки атрибутов класса/экземпляра, перекрывает __init__ класса блокирует поток для создания реестра смапленных классов и делает еще кучу всего
найдите мне 15 человек с адекватным рейтом для проекта со сроками в 1.5 года, на платформу OpenStack которые после отказа от «улучшайзеров» не проклянут меня на чем свет стоит.
вы как-то забываете еще о присутствии курсоров, пуллинге соединений с накладывающимися проверками на привышение лимитов, компилятор sql диалекта в алхимии (ведь ваш код будет работать как минимум на 5-х БД-бэкендах, без изменений), вообще там под капотом от объявления declarative_base и class-mapper до реального запроса к бд лежит довольно внушительный слой кода позволяющий конечному программисту меньше думать об особенности БД и больше о предметной области и взаимодействии сущностей.
Плюс — вы не указали, использовалась алхимия с акселераторами или без. Django-ORM таковых не имеет, поэтому сравнение производительности этих двух решений совершенно некорретно, на мой взгляд.
Пишите хранимые процедуры, не тратьте время на синтетические тесты.
Очень редко, руки лежат по-краям, там для этого достаточно пространства.
В любом случае система распознаёт случайное «задевание» во-время набора текста и адекватно реагирует.
F-клавиши отличаются размером, тактильно это заметно, к тому же, это самый верхний ряд, выше уже ничего нет. Промахнуться сложно. В целом, данное решение используется многими другими компаниями. Та же Sony в линейке VAIO применяет аналогичный подход.
Я не защищаю Apple, как и mba, это сейчас самое адекватное устройство для моих целей помноженных на частые поездки.
Автор пытается акцентировать внимание на на проблемах разработчиков мужского пола и их стремление «кинуть понты» при этом сознательно используя обороты, которые должны задеть людей, являющихся целевой аудиторией данной публикации.
Автор — вы молодец, так держать! Репрезентативность сравнения VB и C# (других технологий же нету) меня завораживает, нежелание освоить базовый язык .NET платформы (VB же был и до .net), а маркетинг МС вполне явно намекает на это, и ваши оправдания заслуживают внимания мастеров кинуть понт.
Всё правильно, асинхронные драйверы есть. Суть в том, что они тоже любят callback одним из аргументов — решение, как я уже говорил — использовать tornado.gen, но если идёт обработка нескольких зависимых сетов — толку от асинхронности — ноль по вдоль.
Проблем-то как раз нет, но местами возникают вопросы — а нужна ли асинхронность при последовательном ожидании результата из data-storage. Когда следующая операция зависит от предыдущей и приходится ожидать.
Лапши колбэков, увы, тоже нету, @gen.engine + gen.Task спасает всё же.
Сейчас уже есть пара мыслей как это «правильно» реализовать с учетом websocket и некоторого времени, прошедшего со старта разработки.
а я вот всерьез рассматриваю пирамиду как опцию с возможностью автогенерации ресурсных урлов, если сейчас еще окажется, что там отдача контента следует RESTful нотации, то плакал ваш Flask далеко позади (и да, в pyramid sqla уже есть). У меня сейчас на той же задаче крутится tornado, скорость и удобство разработки под который заставляет — хм, много думать об альтернативных вариантах.
и кстати, при всей возне никто не рассматривает конкурентом pyramid — интересно — почему бы это? В нем конечно не jinja из коробки, а скорее Mako — синтаксис которой оставляет желать лучшего, но это всё опционально и заменяемо :)
И кстати — приложение в виде одного файла реализуется так же просто как и во Flask
Практически согласен во всём, кроме повального увлечения django — есть куча хороших python-фреймворков отвязанных от ORM совершенно :)
По переносимости — работая ранее с ndb нашел множество похожих подходов у ребят сделавших asyncmongoorm поверх asyncmongo для tornado — так что, если код раньше был на чем-то вроде webapp — перенос не составит труда :)
В составе GAE уже идет набор неплохих «батареек», плюс появление python27 runtime сильно упростило работусо времён, когда была доступна 2.5 версия.
Кстати — странно что пост появился только сейчас CloudSQL анонсировали ажно 7-го ноября, а недавно вышла уже версия 1.6.3 SDK с поддержкой django 1.3
Правда проблем от этого не убавилось — отсутствуют инструменты нормальной миграции базы, что при длительной командной разработке проекта доставляет массу неудобств.
От себя хотел добавить — не нужно было пытаться взгромоздить django поверх Datastore — последний всё же noSQL решение и отношение должно быть соответствующим, но зато там были асинхронные запросы на чтение/запись, и в общем, я его до сих пор считаю неодооцененным. Попробуйте поработать с Datastore не стандартным google.appengine.ext.db а через google.appengine.ext.ndb — который с релиза 1.6.1 появился в составе SDK, Гвидо плохого не напишет :)
Это уже как минимум не актуально
Без сравнения ИМХО получился пост just FYI. =\
Django-ORM — Alex Gaynor, Adrian Holovaty и компания. За конкретикой и критикой — на гитхаб.
Плюс — вы не указали, использовалась алхимия с акселераторами или без. Django-ORM таковых не имеет, поэтому сравнение производительности этих двух решений совершенно некорретно, на мой взгляд.
Пишите хранимые процедуры, не тратьте время на синтетические тесты.
В любом случае система распознаёт случайное «задевание» во-время набора текста и адекватно реагирует.
F-клавиши отличаются размером, тактильно это заметно, к тому же, это самый верхний ряд, выше уже ничего нет. Промахнуться сложно. В целом, данное решение используется многими другими компаниями. Та же Sony в линейке VAIO применяет аналогичный подход.
Я не защищаю Apple, как и mba, это сейчас самое адекватное устройство для моих целей помноженных на частые поездки.
Автор — вы молодец, так держать! Репрезентативность сравнения VB и C# (других технологий же нету) меня завораживает, нежелание освоить базовый язык .NET платформы (VB же был и до .net), а маркетинг МС вполне явно намекает на это, и ваши оправдания заслуживают внимания мастеров кинуть понт.
Лапши колбэков, увы, тоже нету, @gen.engine + gen.Task спасает всё же.
Сейчас уже есть пара мыслей как это «правильно» реализовать с учетом websocket и некоторого времени, прошедшего со старта разработки.
И кстати — приложение в виде одного файла реализуется так же просто как и во Flask
По переносимости — работая ранее с ndb нашел множество похожих подходов у ребят сделавших asyncmongoorm поверх asyncmongo для tornado — так что, если код раньше был на чем-то вроде webapp — перенос не составит труда :)
Кстати — странно что пост появился только сейчас CloudSQL анонсировали ажно 7-го ноября, а недавно вышла уже версия 1.6.3 SDK с поддержкой django 1.3
Правда проблем от этого не убавилось — отсутствуют инструменты нормальной миграции базы, что при длительной командной разработке проекта доставляет массу неудобств.
От себя хотел добавить — не нужно было пытаться взгромоздить django поверх Datastore — последний всё же noSQL решение и отношение должно быть соответствующим, но зато там были асинхронные запросы на чтение/запись, и в общем, я его до сих пор считаю неодооцененным. Попробуйте поработать с Datastore не стандартным google.appengine.ext.db а через google.appengine.ext.ndb — который с релиза 1.6.1 появился в составе SDK, Гвидо плохого не напишет :)