Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 19 14:51
    woarewe starred rom-rb/rom-sql
  • Oct 16 12:09
    Lokideos starred rom-rb/rom-sql
  • Oct 15 22:24
    jodosha starred rom-rb/rom-sql
  • Oct 14 18:36
    katafrakt commented #403
  • Oct 14 18:35
    katafrakt synchronize #403
  • Oct 14 14:15
    katafrakt commented #403
  • Oct 14 11:47
    flash-gordon commented #403
  • Oct 13 22:45
    katafrakt edited #403
  • Oct 13 22:44
    katafrakt edited #403
  • Oct 13 22:43
    katafrakt opened #403
  • Oct 13 22:30
  • Oct 12 06:38
    solnic commented #366
  • Oct 11 23:44
    katafrakt commented #366
  • Oct 08 13:41
    wuarmin commented #163
  • Oct 08 07:33
    wuarmin commented #163
  • Oct 08 07:00
    wuarmin commented #163
  • Sep 27 20:39
    dependabot[bot] labeled #336
  • Sep 27 20:39
    dependabot[bot] labeled #336
  • Sep 27 20:39
    dependabot[bot] opened #336
  • Sep 27 20:39

    dependabot[bot] on bundler

    Bump nokogiri from 1.11.4 to 1.… (compare)

Dawid Lenkiewicz
@dawidlenkiewicz
the end goal is SELECT * FROM ( SELECT DISTINCT ON ..... ORDER BY car_model_id, score) ORDER BY horsepower
so using a subquery
Piotr Solnica
@solnic
@flash-gordon ^^ subqueries are not yet supported OOTB, right?
Nikita Shilnikov
@flash-gordon
nah, not supported, mostly because it’s rarely needed
as in, why do you need a separate query for ordering?
Vasily Kolesnikov
@v-kolesnikov
@flash-gordon I just writing the same question :smile:
Nikita Shilnikov
@flash-gordon
likely it’s related to how distinct on works
for instance, window functions may require subqueries for this because they’re evaluated after ordering IIRC
Dawid Lenkiewicz
@dawidlenkiewicz
yes I need separate query, because the "inside" query uses disctinct on with order, but the "real" ordering should be done outside
ok thx for the help
Nikita Shilnikov
@flash-gordon
window functions are “better” in this regard because they have inline order by
Armin
@wuarmin
Hello, is there a way to truncate all ROM::Relations? I need to truncate all tables after or before each integration-test.
Vasily Kolesnikov
@v-kolesnikov
In the one of my projects where I had two databases under the single ROM container I used to do the following:
TABLES = {
  main_db: rom.relations
              .select { |_, relation| relation.gateway == :main }
              .map    { |_, relation| relation.schema.name.dataset },

  second_db: rom.relations
                .select { |_, relation| relation.gateway == :second }
                .map    { |_, relation| relation.schema.name.dataset }
}.freeze

DatabaseCleaner[:sequel, connection: dbs[:second]]
  .strategy = :truncation, { only: TABLES[:second_db] }

DatabaseCleaner[:sequel, connection: dbs[:main]]
  .strategy = :truncation, { only: TABLES[:main_db] }
Piotr Solnica
@solnic
would be nice to add a built-in solution for this
Nikita Shilnikov
@flash-gordon
tbf I always wonder why people won’t use transactions
Vasily Kolesnikov
@v-kolesnikov
Because of capybara?)
Nikita Shilnikov
@flash-gordon
nah, not an excuse, you can have a shared connection, that’s what I do
    options = {
      test: true,
      single_threaded: persistence.config.env == :test,
      after_connect: inject_pub_connections,
      max_connections: 30
    }
my config
single_threaded ensures the same connection is used by the web server and your test code
you only need to care all http requests are finished before you query database otherwise the connection will blow up (obviously)
Vasily Kolesnikov
@v-kolesnikov
Actually I don't use capybara in my projects. But I prefer to develop in test environment and sometimes I need to explore database state, that is my case.
Piotr Solnica
@solnic
@flash-gordon there are setups where transactions don't work
that's why we need to support various cleaning strategies
Nikita Shilnikov
@flash-gordon
before rushing to it I’d like to know them :) One example is well-known to me, it’s Oracle and non-transactional DDL, what about others?
otherwise providing proper API is guessing
Vasily Kolesnikov
@v-kolesnikov
Piotr Solnica
@solnic
in my current project we have CI configured to use sqlite, using transactions didn't work
I'm just talking about having database cleaner support that works OOTB
so that people can do DatabaseCleaner[:rom_sql]
Nikita Shilnikov
@flash-gordon
@v-kolesnikov yeah I know, but what I meant is real shit, calling DDL from stored procedure where you store your business logic ;) For other cases non-transactional DDL is acceptable, you’re not supposed to call it in tests. In most cases
@solnic does sqlite support transactions? I guess it should
Vasily Kolesnikov
@v-kolesnikov
It just an example, I don't argue.
Piotr Solnica
@solnic
@flash-gordon it does, but it does not work with nested transactions, at least the combination of minitest + database cleaner + sqlite + transactional strategy did not work for me
anyhow, my main point is to have official support for database cleaner, it's the de facto standard and it sucks people need to use :sequel to use it
Nikita Shilnikov
@flash-gordon
I got your point, my point is every time I ask why people use database_cleaner they don’t give me a satisfying answer. OTOH it’s not that I often ask :)
and sequel is not directly involved, I bet you should know how connection pooling works in your app regardless who does the machinery
it’s not that I’m against database_cleaner, I just have never seen a point
Jeff Dickey
@jdickey
Agreed. We started out loving database_cleaner, but we now avoid it because it makes life in Docker more of a special case than we're happy with
Yes, there's a highly reliable workaround, but it's a non-obvious workaround — especially when the error messages you start out chasing lead you in different directions entirely
Armin
@wuarmin
Interesting discussion. I'm using rom
Armin
@wuarmin
sql through hanami-model. The code base is big and we are using multiple postgresql db's and schemas. Hanami does not support multiple db's and schemas at the moment, so just the main db with its public schema is handled by hanami repos. Because of this, the transactional approach does not work everywhere.
Grzegorz Wcisło
@grzegorz-wcislo
Is it possible to combine results from relations from two different adapters (sql and elastic)?
It is a one to one relation
Vasily Kolesnikov
@v-kolesnikov
It isn't native supported yet.
I do it manually in my projects, it is not so complex.
Grzegorz Wcisło
@grzegorz-wcislo
Ok, thanks
winslo
@winslo12_twitter
Hi, I'm just getting started playing around with ROM, and after reading the relations docs I am unsure how we are expected to access the underlying relation in the ROM environment, the way I am doing it now is something like ROM.env.relations[:users] -- this seems odd to me, have I missed something completely?
Tim Riley
@timriley
@winslo12_twitter You typically want to access them through repositories: https://rom-rb.org/4.0/learn/repositories/quick-start/
Piotr Solnica
@solnic
@/all hey y'all, just like in case of dry-rb, we are switching from Gitter to Zulip so please sign up here: https://rom-rb.zulipchat.com/register/ and let's continue chatting on Zulip :smile: