juan_gandhi: (VP)
2015-11-14 02:00 pm
Entry tags:

I wonder do I really need an ORM...

  def dropConstraint(table: String, constraint: String): Unit =
    update(s"alter table $table drop constraint if exists $constraint")

  def dropAllFkeys(): Unit = {
    val found =
      select("constraint_name, table_name from information_schema.table_constraints where constraint_schema='public' and constraint_type = 'FOREIGN KEY'") strings
    for ((k::t::_) <- found) dropConstraint(t, k)
  }
juan_gandhi: (VP)
2013-09-07 10:52 am

А кстати вчера

У меня была пауза между парсерами и проблемами, и пока Чаба переваривает мои рацпредложения, решил немножко поавтоматизировать свой труд по заполнению базы тестовыми данными.

Ну типа руками сдёргиваю экспорт из продакшена (программного доступа не дают), копирую, а потом что, потом надо insert into, с предварительным удалением случайно попавшихся записей с теми же ключами.

Ну а в скале у нас скверил, а скверил идёт на базу и видит, что ключи-то у нас генерируются из последовательности - поэтому он игнорирует ключ, что я даю, ну и т.д.

Ну и ещё, из сиквела с продакшена я получают текст, а скверилу подавай объект, это ещё морока десериализовывать.

Короче, за полдня нафигачил, по мере необходимости, весь нужный мне слой над jdbc, делов-то.

Правильно Tony Morris пишет, проблема ORM, а так же причина существования оной, в том, что производственники ни хера не понимают в программировании.
juan_gandhi: (Default)
2012-12-26 11:53 am

"problem with ORM"

Sure it demonstrates in our inability to do cross-tier refactorings; you change the db, then you do some kind of transaction changing the code, and vice versa.

But we have to understand that this is so for all kinds of distributed data. The language changes in one end of the world, and a tier in the other end has to adapt, changing its language accordingly. Or disconnect. Or start a war. Or introduce United Nations that would keep all the definitions.