8000 Lots of Query · Issue #15 · sorm/sorm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Aug 31, 2022. It is now read-only.

Lots of Query #15

Open
syrm opened this issue Mar 20, 2013 · 10 comments
Open

Lots of Query #15

syrm opened this issue Mar 20, 2013 · 10 comments

Comments

@syrm
Copy link
syrm commented Mar 20, 2013

Why Sorm made lots of query ?
One to get the id.
One other to get the other columns.

  • sql:
    | SELECT DISTINCT
    | t0.id
    | FROM
    | user
    | AS t0
    | WHERE t0.name = ?
    | LIMIT 1
  • data:
    | - oxman
    [debug] s.j.JdbcConnection - Executed statement in 70,066ms:

[debug] s.j.JdbcConnection - Executing statement:

  • sql:
    | SELECT
    | t0.id, t0.email, t0.password, t0.name
    | FROM
    | user
    | AS t0
    | WHERE t0.id = ?
  • data:
    | - 1
@nikita-volkov
Copy link
Contributor

When you deal with more involved entities containing collections, it's impossible to do the fetching of all related data from all the involved tables in a single query. So it's been decided to split the fetching process into two phases: first apply all the filters and orderings to fetch the primary keys, then fetch the actual data by those primary keys, which is cheap anyway.

Optimizations for such things should appear in future versions, but as for now, we'll just have to cope with that.

@syrm
Copy link
Author
syrm commented Mar 20, 2013

This is not cheap at all.
SELECT * FROM ITEMS = 1 query.
But Sorm doing N+1 query where N is the number of entry in ITEMS.

@nikita-volkov
Copy link
Contributor

I've just explained the reasons. The second query is cheap because it's by primary key.

@syrm
Copy link
Author
syrm commented Mar 20, 2013

I know, but this design is very awful.
It should be your primary target.
I respect your work, but you should change that asap :)

@syrm
Copy link
Author
syrm commented Sep 18, 2013

And 6 months later... Nothing changed.

@nikita-volkov
Copy link
Contributor

Read your last two messages. Now please explain to me what made you think that you can talk to me like I owe something to you.

Concerning the issue. It is recognized, that's why it isn't closed, but it is not a critical one, since the framework works fine. If you want it to be addressed sooner, instead of giving me another order just post a pull request.

@syrm
Copy link
Author
syrm commented Sep 18, 2013

I have no competence to do that, sorry.
Its not critical, but close to.
For system with heavy charge it's very close to be a critical problem.

Like I said before, i respect you work, but i'm sad to see no change about that in 6 months :(

@nikita-volkov
Copy link
Contributor

This issue will be addressed in 0.4, but I can't make any promises about when it's going to be released. The project lacks funding, so I simply have to give higher priorities to other projects I make a living from.

@syrm
Copy link
Author
syrm commented Sep 18, 2013

Thanks a lot :-)

@sam-aiq
Copy link
sam-aiq commented Apr 22, 2016

@nikita-volkov: Fetching by primary key isn't necessary cheap when it needs to happen hundreds of times. Also, if the database isn't on the same instance, the network latency can really add up.

in fetchWithSql it does .map( fetchByPrimaryKey ) -- would it be possible for it to instead do .fetchByPrimaryKeys()? Is there a reason that you cannot do something like primary_key IN (x, y, z)?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@syrm @nikita-volkov @sam-aiq
0