Если честно, то первые строчки просто мое отношение к джанго. Манипулировать даже и не пытался. За каждый пункт я могу ответить предметно, почему именно в джанго плохо сделаны орм, шаблоны, формы и тп.
А ругать полезно, особенно когда ругают конкретные моменты. Но вот в случае джанго орма даже ругать нечего предметно. Нормальному человеку и так понятно, что он ничего не может за рамками простейших селектов.
Не всегда вначале пути проекта видно, куда он там идет. Джанго берется по привычке и вперед. А выкидывать старый проект из-за некоторой его части, с которой можно в принципе разобраться — зачем?
Никакого сомнения. Пример с потолка, просто демонстрация того как выглядит запрос в SQLA. Да еще и отличное предостережение, что не надо микроскопом гвозди то заколачивать.
Вы сами то приведите хороший пример. Это сложно достаточно сделать, вырвать из контекста и тому подобное. Поэтому и берется простой дубовый пример с дисклеймером.
Нет, с джанго и ее проблемами я знаком очень давно. Алхимию наш профессионал использует также с успехом продолжительное время и умеет ее готовить.
А с проблемой я столкнулся простой — нужна сложная выборка, которую в итоге написали на raw sql. Получилось неплохо, все работает, но во-первых только на одной БД, а во-вторых вносить в эти запросы изменения адский ад.
От джанго я давно и с успехом отказался везде, где это возможно. Но уже неоднократно здесь указывалось, что отказаться от нее в старом проекте практически невозможно, особенно учитывая большой поток feature запросов от заказчика. А так я предпочел бы не пинать труп, и забить на джангу в комплексе.
1. Модели генерируются при загрузке приложения. Кастомизации не предусматривалось, но в принципе можно и подумать. Только вот тут уже действительно вначале юзе кейс нужен, чтобы сделать то что надо.
2. Да, идет реюз соединения
3. Есть фишки с закрытием транзакций в Django. Так как я использую sqla для выборок, а не для вставок — проблем не возникает
4. Да, модели генерируются один раз. Конечно SQLA кушает свою память, но в момент самого запроса ничего не генерируется заново
5. Хм, кастомные поля это уже сложнее. С другой стороны любое кастомное поле имеет под собой что-то вполне материальное — VARCHAR, INT, TEXT. На данный момент работа с ними будет именно в таком вот, сыром виде.
Реюз коннекта это кстати Владимир Михайленко сделал, за что ему спасибо огромное. Я же стартанул свою библиотеку от его интеграции SQLA в проект, и увел ее в сторону генерации модели данных по Django моделям.
Тесты, да. Обычно я начинаю библиотеки с тестов. У этой они тоже есть, но лежат в секретном проекте. Придется написать отдельные, раз уж библиотека пошла в мир.
Вообще первые комменты как всегда пошли в русли «а чо а нафиг, а докажите мне что оно мне же нужно». Ну вот в этом русле и пошло. Были бы другие вопросы, были бы другие ответы.
Да, я понимаю, что было бы интересно. Парочку привели в комментах, на большее рассчитывать не стоит, у всех своих дел хватает.
«эксперты» явно не доросли. Те, которые доросли, юзе кейсы не просят, они сами все знают. Они себе добавили ссылочку в закладки, и применят aldjemy в подходящем проекте.
А ради товарищей, которые хотят чтобы им значит пояснили предметно, разжевали и в рот положили, напрягаться не вижу никакого смысла. Я таких товарищей не люблю принципиально.
Поэтому я вижу идеальный случай этого топика среди профессионалов так — пост, и вопросы в комментах про особенности реализации. И типа почему сделано так, а не так? Может еще предложение полезное.
А то что я вижу это унылый троллинг от интеллектуалов (сарказм).
Именно. В подавляющем числе случаев не надо SQLA тащить. Я изо всех сил всегда стараюсь за ОРМ не выпрыгивать. Так проект сопровождать легче.
Но бывает иногда, что лучше взять SQLA, чем городить костыли.
Но SQLA можно же где угодно использовать. Можно любой фреймворк взять. Мне вот всегда импонировал Svarga, но вроде решили перенести из него полезное во Flask, и не разводить зоопарк. В принципе я того же мнения, но жалко :) Он мне нравился.
Я и без вас их могу оценить прекрасно. Более того, я это сделал еще до первой строчки aldjemy, и пару разу перепроверил, что джанго орм мне точно ничем не поможет. И raw sql тоже.
Выкладывать задачи не буду. Можно удовлетворить свой интерес за разработкой своего проекта. А проекты с тонной кода как бы не для общего обозрения обычно, и с NDA.
А ругать полезно, особенно когда ругают конкретные моменты. Но вот в случае джанго орма даже ругать нечего предметно. Нормальному человеку и так понятно, что он ничего не может за рамками простейших селектов.
Работает со вложенными структурами.
А так я полностью согласен на джанго не писать :)
Вы сами то приведите хороший пример. Это сложно достаточно сделать, вырвать из контекста и тому подобное. Поэтому и берется простой дубовый пример с дисклеймером.
Нет, с джанго и ее проблемами я знаком очень давно. Алхимию наш профессионал использует также с успехом продолжительное время и умеет ее готовить.
А с проблемой я столкнулся простой — нужна сложная выборка, которую в итоге написали на raw sql. Получилось неплохо, все работает, но во-первых только на одной БД, а во-вторых вносить в эти запросы изменения адский ад.
От джанго я давно и с успехом отказался везде, где это возможно. Но уже неоднократно здесь указывалось, что отказаться от нее в старом проекте практически невозможно, особенно учитывая большой поток feature запросов от заказчика. А так я предпочел бы не пинать труп, и забить на джангу в комплексе.
2. Да, идет реюз соединения
3. Есть фишки с закрытием транзакций в Django. Так как я использую sqla для выборок, а не для вставок — проблем не возникает
4. Да, модели генерируются один раз. Конечно SQLA кушает свою память, но в момент самого запроса ничего не генерируется заново
5. Хм, кастомные поля это уже сложнее. С другой стороны любое кастомное поле имеет под собой что-то вполне материальное — VARCHAR, INT, TEXT. На данный момент работа с ними будет именно в таком вот, сыром виде.
Тесты, да. Обычно я начинаю библиотеки с тестов. У этой они тоже есть, но лежат в секретном проекте. Придется написать отдельные, раз уж библиотека пошла в мир.
Да, я понимаю, что было бы интересно. Парочку привели в комментах, на большее рассчитывать не стоит, у всех своих дел хватает.
А ради товарищей, которые хотят чтобы им значит пояснили предметно, разжевали и в рот положили, напрягаться не вижу никакого смысла. Я таких товарищей не люблю принципиально.
Поэтому я вижу идеальный случай этого топика среди профессионалов так — пост, и вопросы в комментах про особенности реализации. И типа почему сделано так, а не так? Может еще предложение полезное.
А то что я вижу это унылый троллинг от интеллектуалов (сарказм).
Но бывает иногда, что лучше взять SQLA, чем городить костыли.
Имею право послать всех «экспертов» которые думают иначе.
Выкладывать задачи не буду. Можно удовлетворить свой интерес за разработкой своего проекта. А проекты с тонной кода как бы не для общего обозрения обычно, и с NDA.
Речь идет об интеграции SQLA в существующий проект, который не надо переписывать.