Конструкторы такие конструкторы (рабочее)
... точнее, конструкторы в Java классах
не люблю я ругаться на чужой код. но иногда порыв души не остановить :)
дебажил намедни GORM на предмет перегрузки кода. Как известно, GORM - это обёртка над Hibernate 3, и живёт это всё в Grails. Соответственно, там ещё есть и Spring 3, который замечательно служит связывающим звеном во всём этом винигрете.
Если коротко, то Grails - это полшый фарш - Groovy, Spring, Hibernate и кое-где ещё bytecode magic... конвенции там, все дела. Красиво вобщем. (никто не уловил язвительности во всём этом рассказе? :] )
Ну так вот. Чтобы всё замечательно перегружалось нашим супер-продуктом и замечательно работало, мне надо дёргать внутри фреймворка за некоторые ниточки. Ниточки эти - всё что угодно - public-методы, private-методы, заного сгенерированный код... всё, кроме конструкторов.
Последнияя фишка в Grails (собственно, и единственная) которую мне осталось заставить работать - это перегрузка ORM-модели. Цель такая - добавляю новый атрибут в класс - компилирую - вижу результат. Без перезапуска сервака и без переразвёртывания приложения. При умелом конфигурировании фреймворка, и использовании JRebel, ORM - это единственная вещь в Grails (известная мне), которая (пока что) не перегружается "на лету".
Вобщем, добился я того чтобы новые атрибуты, и новые связи между объектами появлялись "на лету". Но вот проблема, новые атрибуты не сохраняются в базу. Да и при создании новых записей, тоже, приложение сваливается с ошибкой при записи в базу - "cannot insert null". Видимо, в дебрях обёрток, проксей, фабрик, и ещё кто-где-что-фиг-знает-чего сидят закешированные объекты и не обновляются при появлении новых атрибутов класса. Грубо говоря, надо это всё заного проинициализировать (слово то какое!).
просидел в дебаггере уже без малого неделю
В Hibernate, который собственно во всём всегда и виновен, было полно мест, где по логике фреймворка, я мог бы запустить тот или иной отрезок кода, и всё бы (возможно) заработало бы. Но почти всегда этот код находился в конструкторах классов этого фреймворка. Вы посмотрите на этот монстрообразный конструктор в SessionFactoryImpl!!! "Ну ёп...!", вырвалось у меня. И таких мест - пруд пруди.
Вобщем, Капетан Очевидность нам как бы подсказывает, какая-либо логика в конструкторе - это зло! Если уж очень надо - вынесене эту логику в отдельный метод, и потом вызывайте этот метод в конструкторе. А так, зачем делать жизнь труднее другим собратьям по цеху..
не люблю я ругаться на чужой код. но иногда порыв души не остановить :)
дебажил намедни GORM на предмет перегрузки кода. Как известно, GORM - это обёртка над Hibernate 3, и живёт это всё в Grails. Соответственно, там ещё есть и Spring 3, который замечательно служит связывающим звеном во всём этом винигрете.
Если коротко, то Grails - это полшый фарш - Groovy, Spring, Hibernate и кое-где ещё bytecode magic... конвенции там, все дела. Красиво вобщем. (никто не уловил язвительности во всём этом рассказе? :] )
Ну так вот. Чтобы всё замечательно перегружалось нашим супер-продуктом и замечательно работало, мне надо дёргать внутри фреймворка за некоторые ниточки. Ниточки эти - всё что угодно - public-методы, private-методы, заного сгенерированный код... всё, кроме конструкторов.
Последнияя фишка в Grails (собственно, и единственная) которую мне осталось заставить работать - это перегрузка ORM-модели. Цель такая - добавляю новый атрибут в класс - компилирую - вижу результат. Без перезапуска сервака и без переразвёртывания приложения. При умелом конфигурировании фреймворка, и использовании JRebel, ORM - это единственная вещь в Grails (известная мне), которая (пока что) не перегружается "на лету".
Вобщем, добился я того чтобы новые атрибуты, и новые связи между объектами появлялись "на лету". Но вот проблема, новые атрибуты не сохраняются в базу. Да и при создании новых записей, тоже, приложение сваливается с ошибкой при записи в базу - "cannot insert null". Видимо, в дебрях обёрток, проксей, фабрик, и ещё кто-где-что-фиг-знает-чего сидят закешированные объекты и не обновляются при появлении новых атрибутов класса. Грубо говоря, надо это всё заного проинициализировать (слово то какое!).
просидел в дебаггере уже без малого неделю
В Hibernate, который собственно во всём всегда и виновен, было полно мест, где по логике фреймворка, я мог бы запустить тот или иной отрезок кода, и всё бы (возможно) заработало бы. Но почти всегда этот код находился в конструкторах классов этого фреймворка. Вы посмотрите на этот монстрообразный конструктор в SessionFactoryImpl!!! "Ну ёп...!", вырвалось у меня. И таких мест - пруд пруди.
Вобщем, Капетан Очевидность нам как бы подсказывает, какая-либо логика в конструкторе - это зло! Если уж очень надо - вынесене эту логику в отдельный метод, и потом вызывайте этот метод в конструкторе. А так, зачем делать жизнь труднее другим собратьям по цеху..