Комментарии 46
НЛО прилетело и опубликовало эту надпись здесь
Разве это сложный запрос? Так, подразукрашенный простенький, но strict sql.
Есть по мелочам ещё придирки - int - это всегда не unsigned в Mysql - мне жаба давит просто так отдавать лишнее. Понятно, что для совместимости между базами, но это ли важно, если выбор уже сделан?
Разве это не отвратительно, когда стандарт фреймворка подразумевает иметь поле одинаковое поле id во всех таблицах? И когда фреймворк за тебя принимает решения о users=>user, managers=>manager (я про hz=>hzs?) - это false mind. Поначалу прикольно, подаётся как фича, не более того.
routes - полный отстой без хаков.
Для хостинга - это Вам не php - нет mod_php - будет mongrel + проксик апач, значит, что множество стартаперов просто не смогут провернуть дело правильно без хотя бы vps.
Есть по мелочам ещё придирки - int - это всегда не unsigned в Mysql - мне жаба давит просто так отдавать лишнее. Понятно, что для совместимости между базами, но это ли важно, если выбор уже сделан?
Разве это не отвратительно, когда стандарт фреймворка подразумевает иметь поле одинаковое поле id во всех таблицах? И когда фреймворк за тебя принимает решения о users=>user, managers=>manager (я про hz=>hzs?) - это false mind. Поначалу прикольно, подаётся как фича, не более того.
routes - полный отстой без хаков.
Для хостинга - это Вам не php - нет mod_php - будет mongrel + проксик апач, значит, что множество стартаперов просто не смогут провернуть дело правильно без хотя бы vps.
Знаете, сама концепция фреймворка предполагает наличие определенных соглашений и ограничений, в т.ч. в именовании, иначе рано или поздно это уже фреймворком не будет. Впрочем, если вы почитаете документацию по рейлсу повнимательнее, обнаружите, что имена для таблиц можно задавать произвольно. Про id не помню, но думаю, что решение тоже есть.
это очаровательно, когда стандарт фреймворка подразумевает.
И когда некоторые пишут это руками, они понимают, что происходит на самом деле.
НЛО прилетело и опубликовало эту надпись здесь
не хотелось бы переводить в личное,
Мне VPS не актуален - свои сервера, да это и не так важно, забудем о моей маленькой письке.
SQL руками - пропадает весь объектный цимус сразу же - уже пробовал - в том и фишка ROR, что всё цельно, шаг в сторону и многое становится неинтересным.
routes - слишком туповато, что url изначально очень жёстко задаётся в routes.rb - controller/action/year/2007/month/04
Если бы можно сделать так, чтобы controller/action/month/04/year/2007/opa/blia и одновременно controller/action/opa/blia
было бы здорово, но изначально меня подводят к тому, что это приводит к описанию кучи маршрутов, в которых сам путаюсь. А делов то просто в переменных разных внутри контроллера, что так сложно разобрать url изначально?. Слишком жёсткие routes для начинающих.
Я говорю именно про Active Record - тянуть за собой кучу незнамо какого кода, который формирует ещё далеко не факт, что оптимальный sql(очень не факт), именно на сложных запросах - есть нужда сейчас во вложенных - так там просто ээээ... Я уже пояснил как оно к MYSql относится - забывает про unsigned - ну нету его и уравнивает id, что даже потом, когда отдельный модуль на другом языке пишешь к базе заипёсся вспоминать где какой id.
Отсутствие поддержки встроенной foreign keys - это полный писец!!! Прошлый век!!! Плагинами можно, но...
Масштабируется оно в теории хорошо, но на практике не видно ничего кроме Basecamp и его друзей - тормознутая хреновина до следующей версии.
Мне VPS не актуален - свои сервера, да это и не так важно, забудем о моей маленькой письке.
SQL руками - пропадает весь объектный цимус сразу же - уже пробовал - в том и фишка ROR, что всё цельно, шаг в сторону и многое становится неинтересным.
routes - слишком туповато, что url изначально очень жёстко задаётся в routes.rb - controller/action/year/2007/month/04
Если бы можно сделать так, чтобы controller/action/month/04/year/2007/opa/blia и одновременно controller/action/opa/blia
было бы здорово, но изначально меня подводят к тому, что это приводит к описанию кучи маршрутов, в которых сам путаюсь. А делов то просто в переменных разных внутри контроллера, что так сложно разобрать url изначально?. Слишком жёсткие routes для начинающих.
Я говорю именно про Active Record - тянуть за собой кучу незнамо какого кода, который формирует ещё далеко не факт, что оптимальный sql(очень не факт), именно на сложных запросах - есть нужда сейчас во вложенных - так там просто ээээ... Я уже пояснил как оно к MYSql относится - забывает про unsigned - ну нету его и уравнивает id, что даже потом, когда отдельный модуль на другом языке пишешь к базе заипёсся вспоминать где какой id.
Отсутствие поддержки встроенной foreign keys - это полный писец!!! Прошлый век!!! Плагинами можно, но...
Масштабируется оно в теории хорошо, но на практике не видно ничего кроме Basecamp и его друзей - тормознутая хреновина до следующей версии.
Да, с foreign keys конечно нехорошо получилось. Но обещают исправиться ко второй версии.
интересно, конечно, но как испытательный полигон был выбран python. А пока там тоже многое не решили (unicode) до python 3000, альфа которого обещается в августе, я решил вообще не дёргаться.
ещё проблема с хостингом - я ставлю если у себя mongrel или с python - mod_python - нет там поддержки shared hosting, вот я "кладу" такого клиента на хостинг, так ещё и вынужден париться по этому поводу - ведь если fcgi так память откушает личную, а в shared даже mod_python не готов - будет лазить по всему диску с правами питона. Это только вариант для своих серверов. В случае с rails - mongrel будет кушать личный. А как продвигать в массы технологию, которая стоит уже изначально дороже. php тут непобедим, к сожалению. А для frontend, в зависимости от фреймворка php вообще офигителен. А вот с тылу оно конечно да... Всё таки питон.
НЛО прилетело и опубликовало эту надпись здесь
AR отлично подходит для CRUD, а вот select запросы лучше всего делать посредством helper объектов и dataset, используя обычный SQL. Это распространенная практика.
НЛО прилетело и опубликовало эту надпись здесь
Ничего=) Простите, что говорю, что думаю, пока свободен как от людей так и от технологий. Такое тоже не часто бывает. Я очень рад, что не нужно привязываться к чему либо, лишь бы это позволило заработать денег и идей всем технарям хотя бы за ближайшую пятилетку, всё ведь проходит и хочется искать. Про Twitter знаю только то, что его открыли первым 10.000 зарегистрированных и я его пока не видел. Как же хотелось найти, что-то убойное, вместо того, чтобы искать недостатки!
про фреймворк свой - самописный - друг писал, я в основном люблю реализовывать именно - он любит системщину, предвидел MVC, простой и понятный, постоянно пытаюсь спрыгнуть, но и не на что, вот недостатки ищу для себя в новом. Так и не нашёл пока, оттого и ругаюсь.
НЛО прилетело и опубликовало эту надпись здесь
Это в каком году ваш друг предвидел MVC?
Если убрать мусор, получится:
SELECT * FROM products
LEFT OUTER JOIN product_images ON product_images.product_id = products.id WHERE (sub_category_id = '1')
ORDER BY sub_category_id, products.position
Не вижу ничего страшного и тем более сложного в таком запросе.
SELECT * FROM products
LEFT OUTER JOIN product_images ON product_images.product_id = products.id WHERE (sub_category_id = '1')
ORDER BY sub_category_id, products.position
Не вижу ничего страшного и тем более сложного в таком запросе.
к сожалению, сколько бы фреймворков небыло, всегда найдутся запросы, которые придётся писать руками
либо с точки зрения оптимальности, либо потому что просто нет другого выхода получить именно те данные, которые нужно
либо с точки зрения оптимальности, либо потому что просто нет другого выхода получить именно те данные, которые нужно
Несмотря на то, что в RoR лучшая по мнению многих (я в их числе) реализация AR, сам паттерн не является "серебрянной пулей". M:N отношения без вспомогательного класса отобразить не получится, с наследованием классов, для которых AR является базовым, уже возникают проблемы. С действительно сложными запросами (с having и группировками) тоже не все гладко. В общем решение очень хорошее, но не стоит относиться к нему с фанатизмом.
ActiveRecord - это не паттерн, это библиотека. Паттерн, который реализует ActiveRecord, называется ORM.
ORM - это технология программирования
Active Record - одиз из паттернов, который ее реализует. Есть также Data Mapper, Table Data Gateway.
В RoR ActiveRecord - это реализация паттерна active record
Active Record - одиз из паттернов, который ее реализует. Есть также Data Mapper, Table Data Gateway.
В RoR ActiveRecord - это реализация паттерна active record
В том, что это паттерн можно убедиться на той же википедии ;)
Автор народ запутал :)
ORM - это техника (концепция отчасти) или ряд приемов отображения реляционных данных в объекты. Она позволяет достаточно прозрачно работать с реляционными базами данных, манипулирую объектами приложения.
Active Record - паттерн (причем не единственный), который эту технику реализует: http://www.martinfowler.com/eaaCatalog/a…. Также рекомендую почитать про другие паттерны на этом сайте, тогда станет более ясна концепция ORM и Active Record в частности. Для тех кому эта тема действительно интересна и у кого есть опыт, стоит также почитать замечательную книгу Мартина Фаулера "Patterns of Enterprise Application Architecture".
Active Record - это также название библиотеки для Ruby (http://api.rubyonrails.com/classes/Activ…), которая часто используется в качестве модели при использования паттерна MVC, причем не только в рельсах :)
По поводу статьи - средняя, название не соответствует содержимому, хотя автор просил не критиковать и не брузжать, так что не буду.
ORM - это техника (концепция отчасти) или ряд приемов отображения реляционных данных в объекты. Она позволяет достаточно прозрачно работать с реляционными базами данных, манипулирую объектами приложения.
Active Record - паттерн (причем не единственный), который эту технику реализует: http://www.martinfowler.com/eaaCatalog/a…. Также рекомендую почитать про другие паттерны на этом сайте, тогда станет более ясна концепция ORM и Active Record в частности. Для тех кому эта тема действительно интересна и у кого есть опыт, стоит также почитать замечательную книгу Мартина Фаулера "Patterns of Enterprise Application Architecture".
Active Record - это также название библиотеки для Ruby (http://api.rubyonrails.com/classes/Activ…), которая часто используется в качестве модели при использования паттерна MVC, причем не только в рельсах :)
По поводу статьи - средняя, название не соответствует содержимому, хотя автор просил не критиковать и не брузжать, так что не буду.
x.name = "Иван Иванов"
на хабре вместо мифических Иванов Ивановых и Васей Пупкиных принято использовать имя "Роман Иванов" :-(
то что написал автор - это верхушка айсберга... которая конечно довольно сильно упрощает работу...
по себе могу сказать, что много пишу на пхп использую довольно удобные адаптеры для бд...
но точто в рельсах упрощает всё во много раз.. меньше кода..
например очень удобно использовать:
User.new(params[:user]).save
а данные передаются из формы где и присутствуют все поля.
а все проверки и прочие действия с данными переносим в файл модели...
также удобно апдейтить)
User.find(id).update_attributes(params[:user])
но самая прелесть конечно не в этом, а в уже пристутствующем механизме работы со звязями (один к одному, один ко многим, и многие ко многим (через дополн таблицу))
очень удобно например находить посты пользователя
u = User.find(id)
u.post.each {|p|
p.title
p.text
p.comment.each { |c|
c.user.name # это конечно если между юзером и коментами есть связь...
c.text
}
}
помоему всё действительно просто и крассиво.
хотя конечно порой приходится писать обычные sql запросы.
по себе могу сказать, что много пишу на пхп использую довольно удобные адаптеры для бд...
но точто в рельсах упрощает всё во много раз.. меньше кода..
например очень удобно использовать:
User.new(params[:user]).save
а данные передаются из формы где и присутствуют все поля.
а все проверки и прочие действия с данными переносим в файл модели...
также удобно апдейтить)
User.find(id).update_attributes(params[:user])
но самая прелесть конечно не в этом, а в уже пристутствующем механизме работы со звязями (один к одному, один ко многим, и многие ко многим (через дополн таблицу))
очень удобно например находить посты пользователя
u = User.find(id)
u.post.each {|p|
p.title
p.text
p.comment.each { |c|
c.user.name # это конечно если между юзером и коментами есть связь...
c.text
}
}
помоему всё действительно просто и крассиво.
хотя конечно порой приходится писать обычные sql запросы.
превед, kukutz!
Скажите пожалуйста, вот если мне RoR целиком не нужен, а хотелось бы использовать в своем проекте только ActiveRecord или другой его компонент - это возможно, и если да - то как?
Спасибо.
Спасибо.
НЛО прилетело и опубликовало эту надпись здесь
ActiveRecord идет отдельной библиотекой (gem - ом) - поэтому им можно пользоваться отдельно от RoR
Порядок такой
1. Устанавливаете ActiveRecord gem
2. Пишете что то типа такого
require "active_record"
ActiveRecord::Base.establish_connection(
:adapter => "mysql",
:host => "localhost",
:username => "myuser",
:password => "mypass",
:database => "somedatabase"
)
#А дальше все как в RoR
class User < ActiveRecord::Base
end
u = User.find( :all)
и т.д.
Порядок такой
1. Устанавливаете ActiveRecord gem
2. Пишете что то типа такого
require "active_record"
ActiveRecord::Base.establish_connection(
:adapter => "mysql",
:host => "localhost",
:username => "myuser",
:password => "mypass",
:database => "somedatabase"
)
#А дальше все как в RoR
class User < ActiveRecord::Base
end
u = User.find( :all)
и т.д.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Философия ActiveRecord