Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 09 12:04
    wuarmin commented #407
  • Aug 09 11:40
    flash-gordon commented #407
  • Aug 09 07:02
    wuarmin commented #407
  • Jul 28 23:51
    Clivern starred rom-rb/rom-sql
  • Jul 28 16:44
    elct9620 commented #389
  • Jul 28 16:25
    elct9620 commented #389
  • Jul 28 16:18
    elct9620 commented #389
  • Jul 28 16:15
    elct9620 commented #389
  • Jul 28 14:47
    elct9620 commented #389
  • Jul 21 23:20
    dependabot[bot] labeled #345
  • Jul 21 23:20
    dependabot[bot] labeled #345
  • Jul 21 23:20
    dependabot[bot] opened #345
  • Jul 21 23:20

    dependabot[bot] on bundler

    Bump tzinfo from 1.2.9 to 1.2.1… (compare)

  • Jul 02 06:00
    cuilei5205189 starred rom-rb/rom-rb.org
  • Jun 26 10:04
    chee-k starred rom-rb/rom-sql
  • Jun 14 20:47
  • Jun 01 05:15

    solnic on main

    Switch to peaceiris/actions-gh-… (compare)

  • May 28 10:20

    solnic on main

    Remove GA (compare)

  • May 27 16:41
    dependabot[bot] labeled #344
  • May 27 16:41
    dependabot[bot] labeled #344
Oskar Szrajer
@gotar
but probably @solnic will describe and explain it better
Piotr Solnica
@solnic
yes, primary reason for relation views is chaining and composition
and repos are first and foremost the boundary between your app and persistence
Dawid Lenkiewicz
@dawidlenkiewicz

but shouldn't repositories (in theory) always return "materialized" data ?

Like:

# in relation
def for_user(user)
  where(user_id: user.id)
end

# in repo
def for_user(user)
  posts_relation.for_user(user).to_a
end
Oskar Szrajer
@gotar
yeah
you use relations to build (chain) logic (query) and in repo you finish with objects (tuples)
Ethan Turkeltaub
@ethnt
@solnic @gotar @dawidlenkiewicz I think that makes sense. So a summary would be: use repositories to compose the views from relations and to return materialized data?
@solnic @gotar I've wondered, why is the pattern of [](arg) used a lot with ROM/dry over a different method?
Oskar Szrajer
@gotar
a convention, like to use .() in place of .call
[] can be user as a .call to
but mostly it's user like a key in hash
{a: 1, b: 2}[:a]

and

def [](id)
   ...
end

user[12] # => is like user.find_by_id(12)

not sure it's the best explanation
[6] pry(main)> add = -> (a,b) { a + b}
=> #<Proc:0x00005567f9a1eee0@(pry):6 (lambda)>
[8] pry(main)> add.call(1,2)
=> 3
[9] pry(main)> add.(1,2)
=> 3
[10] pry(main)> add[1,2]
=> 3
Oskar Szrajer
@gotar
so when you used to use [] in a hash, in a procs it's somehow natural (for me) to use like users[12] #=> give me user by ID equal 12
hope it answers to your question somehow
Ethan Turkeltaub
@ethnt
Yes, that makes sense! I was just curious about the backstory :)
Oskar Szrajer
@gotar
for real backstory you will need to do a git blame and find the authors :p
but I hope it gives you some explanation ;]
Piotr Solnica
@solnic
another concept is to use .() shortcut for objects that are pure (so no side-effects), but I failed to use it like that consistently :) I just like typing .() instead of .call :D
S.Tamiya
@ablce9

I have a question here. Basically I have three tables and need to left-join two of them. SQL here MySQL [account]> select email,role,main_email from users left join tenants_users on (tenants_users.user_uuid = users.uuid) left join tenants on (tenants.main_email = users.email);.
I got this instead,

[86] pry(main)> db.from(:users).select(:email).left_join(:tenants_users, user_uuid: :uuid).select_append(:role).left_join(:tenants, main_email: :email)
=> #<Sequel::Mysql2::Dataset: "SELECT `email`, `role` FROM `users` LEFT JOIN `tenants_users` ON (`tenants_users`.`user_uuid` = `users`.`uuid`) LEFT JOIN `tenants` ON (`tenants`.`main_email` = `tenants_users`.`email`)">

I like to replace tenants_users.email with users.email.

I wonder how I can explicitly write left join tenants on (users.email = tenants.main_email) ???
Oskar Szrajer
@gotar
@ablce9 left_join(:tenants, { main_email: :email }, table_alias: :users) i guess
Nikita Shilnikov
@flash-gordon
this is falling back to sequel, rom-sql from master has first class support for it. ATM releasing a matter of a couple of months
Oskar Szrajer
@gotar
but that should do the job as I know
@flash-gordon and how new ROM support for this looks like?
Nikita Shilnikov
@flash-gordon
it's on the changelog
Oskar Szrajer
@gotar
ok :)
Nikita Shilnikov
@flash-gordon
there should be nice examples
Oskar Szrajer
@gotar
yeah :) nice one thx
S.Tamiya
@ablce9
@flash-gordon Thanks. I somehow figures using Sequel.lit(users.email).
ohh, sorry @gotar
Oskar Szrajer
@gotar
Sequel.lit() generally should never be used (all should be achievable in ROM, without calling Sequel directly)
S.Tamiya
@ablce9
Yeah, but this is one time only. The code is meant for a migration.
Nikita Shilnikov
@flash-gordon
I actually write migrations in pure SQL :)
data migrations I mean
S.Tamiya
@ablce9
The project I'm working on generally stores migration file around db/migration . Is that common to write pure SQL when doing migration?
Nikita Shilnikov
@flash-gordon
well, depends on your SQL skills :) Data migrations are kind of one-way anyway and I don't want anything between me and database during the migration. And it's usually faster
personally, I wrote a lot of SQL so this is a non-issue for me
S.Tamiya
@ablce9
I realized it's really tricky converting SQL code into Sequel. and what worse is Sequel is not that supportive I guess? so I come here and ask for helps and people here are really supportive, thanks.
Nikita Shilnikov
@flash-gordon
We discourage from Sequel when possible, our plan is provide people with the tools required for that
Sequel is sort of low level in general and leaks too much SQL related stuff
OTOH migrations is a different beast
esp data migrations
S.Tamiya
@ablce9
gotcha!
Ethan Turkeltaub
@ethnt
Hi guys, another question. I have a recursive relation: a country has many regions, which has many regions. is there a way to recursively get all of the regions of a country?
countries_repositories.aggregate(region: :region) gets the first two layers but not below that
Piotr Solnica
@solnic
@ethnt there's no special feature to cover this. You could write some smart query yourself to get it effectively.
Ethan Turkeltaub
@ethnt
@solnic Good to know, thanks :+1: