Как стать автором
Обновить

Комментарии 19

Я в свое время что то аналогичное писал just for fun. И даже реализовал «foreign key».
А думали как делать выборку сразу из двух таблиц?

Есть одна идея. Можно, например, сделать как-то так:


class City {
    int id;
    String name;
}

class Person {
    String fullName;
    @ObjectLink(columnName="cityId",linkToField="id")
    City city;
}
Сейчас порылся в старом коде, я foreign ley делал без аннотаций :)

Да когда то давно мой первый тим лид тоже дал таск на саморазвитие написать мини хибернейт. Сразу после этого с любым фреймворком стало проще работать зная что под капотом. Но рефлексия по полям только этого мало. Попробуйте на досуге генерить используя методы. Может как и я споткнетесь с проблемой boolean vs Boolean геттерами))

кстати да :)
с методами все становится намного интереснее :)
НЛО прилетело и опубликовало эту надпись здесь

Как обстоят дела с sql-инъекциями? Исходя из того, что я увидел, Ваш 'фреймворк' их полностью поддерживает)

String valueString = value!=null ? "'" + value.toString().replace("'","\\'") + "'" : "NULL";

По идее подобное экранирование должно обезопасить от инъекций. Или я не прав? )

Не только ковычки нужно экранировать

Не только. Символы комментариев,, точка с запятой. А можно не изобретать велосипед и воспользоваться prepared statement где уже бородатые дядьки в своё время всё сделали))

Добавил такое вот:


private static String escapeString(String str) {
        return "'" +
                str
                .replace("\\", "\\\\")
                .replace("\0", "\\0")
                .replace("'", "\\'")
                .replace("\"", "\\\"")
                .replace("\b", "\\b")
                .replace("\n", "\\n")
                .replace("\r", "\\r")
                .replace("\t", "\\t")
                + "'";
    }
Вообще эти штучки используют лишь 1% возможностей sql запросов. С точки зрения их разработчика — да, это интересно, но с точки зрения практического применения результат близок к 0. Время потраченное на изучение и применения этого — лучше потратить на более полное изучение sql. А насчет инъекций — полная защита — использование хранимых процедур. Они подвержены инъекции если только писавший их специально даст такую возможность.

Сорри, случайно поставил минус вместо плюса. Полностью поддерживаю по первой части. А по поводу инъекций — нафиг хранимые процедуры, достаточно PreparedStatement и '?'.

достаточно PreparedStatement и '?'
практически да, но возможности хранимки больше.
НЛО прилетело и опубликовало эту надпись здесь
ОРМы очень широко используются.
то что они используются — не подтверждает тот факт, что возможности sql они используют полностью.
Хранимые процедуры, это конечно здорово, но иметь логику в двух местах — в сервере приложений и в БД — не самая лучшая мысль.
утвержение спорное. для меня, достаточно хорошо знающего sql, нет сложности, я выбираю компромис, стараюсь чтоб система работала быстрее и была понятнее в сопровождении.
Для всего остального, чистый SQL — долго и дорого.
я б не сказал что дорого и долго, есть хорошие инструменты (не в качестве рекламы — dbForge for mysql) которые позволяют все делать качественно и быстро. Причём хранимые процедуры даже дебажить. и тут есть огромное ускорение — даже небольшой запрос изменить проще в гуи, отладить и прочее. Мы не трогаем код программы, не компилируем, не запускаем. Изменили хранимку — проверили. а ведь если запрос на 2-3 экрана? чтоб что-то изменить, проверить… и перенести в основной код, вставить как строку, проверить все кавычки… откомпилировать, сделать кучу действий, чтоб дойти до нужного места где производится вызов запроса…
К сожалению в последнее время мало уделяют обучению sql. Всё больше используют «хибер», считая его панацеей для решения задач. Но по мне — это «прокладка»… Это первое. Второе — когда смотришь, что делается с помощью хибера и ему подобных, понимаешь, что люди пытаются повторить возможности субд, не имея для этого знания. А это уже сказывается на качестве системы.

А почему вы решили сделать включение IF NOT EXISTS на уровне сущности, а не на уровне параметра метода createTable()?


Не смог легко придумать сценарий, когда имеет смысл делать разные настройки для разных сущностей, а вот аннотации развешивать, если что, придётся везде.

Тоже думал включить его на уровне параметра. Но в конце концов, поскольку используются аннотации, решил сохранить единый стиль.

Выглядит неплохо, но насколько я понял в текущей версии аннотации являются только разметкой для генерации запроса, но не позволяют контролировать изменение полей. Например @MaxLength(1024) не помешать записать в поле объекта строку большей длины и ошибка возникнет только при сохранении в базу данных. Интересно есть ли реализации которые позволяют генеренировать Java-код который контролирует выполнение ограничений на поля объекта (примерно как в Lombok).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории