Relation#last doesn't respect as

[jodosha]

I'm using rom-sql via rom-repository as integration with hanami-model.

From my repository, if I use #first with as it works fine:

def first
  users.as(:entity).first
end

###

repository.first.class # => User

But this isn't respected with #last:

def last
  users.as(:entity).last
end

###

repository.last.class # => Hash

To overcome to this problem, I implemented #last as follow:

  def last
    users.order(Sequel.desc(users.primary_key)).as(:entity).first
  end

The complete setup can be found here: https://github.com/hanami/model/blob/6ea119ebc308cd745fa03d5e7729678bc16d6dd2/test/support/fixtures.rb#L28

[solnic]

Sorry for not addressing this, it's more tricky than it seems to be, because first and last are implemented in relations, and they already return tuples, so they can't go through mapping pipeline.

Notice that first materializes the whole relation, then returns its first element. This means that all tuples are fetched - so, better not to use it.

We have a dedicated API for fetching a single tuple: one and one! and this should be used instead of first and last.

I would suggest doing this if you really want to have these methods available on repos with automapping:

def first
  users.limit(1).as(:entity).first
end

def last
  users.limit(1).as(:entity).reverse.first
end

I'll close this, it's not going to be changed in rom. I may even remove first and last in rom-sql 2.0.0 because it may cause confusion. I'll report a new issue explaining this problem and ref this one.

[jodosha]

@solnic Thanks for getting back. No worries. 👍

[cllns]

Thanks for explaining this @solnic. It's something I hadn't thought of, but it's a terrific insight.

I have one misunderstanding. It's probably my fault :)

Did you mean to have the example code-block as:

def first
  users.limit(1).as(:entity).one
end

def last
  users.limit(1).as(:entity).reverse.one
end

(instead of calling first, because you said first materializes the whole relation, then returns its first element.)

Or does first act differently after limit and as?

[solnic]

Or does first act differently after limit and as?

since we add limit then it'll be only one tuple :)

[cllns]

ah, I see. so it doesn't matter because you're just materializing a single element

[solnic]

@cllns exactly. I should mention that one has different semantics because it expects that there will be a single tuple, and will raise if there's more than one, and one! will raise when there's no tuple or more than one. So it's a very intentional method (and actually saves you from bugs).

[cllns]

thanks! Yes, I saw that distinction and understand it :)