Add database field expression (such as Person::Fullname)

Rails
1

I am new to Rails development, having done c++ and other database driven
app development in the past. Often I would create a database view that
would combine, for example, first and last name values into a “virtual”
field called FullName.

I don’t see how to use database views with Rails, so I am thinking that
another way to this would be to define a virtual attribute on the
appropriate class to do the same thing (the derived ActiveRecord or
ApplicationController classes?), but I am unclear where and how this
should be declared.

Can anyone point me in the right direction?

Kevin

2

On 7/17/07, Kevin A. [email protected] wrote:

should be declared.

Can anyone point me in the right direction?

ActiveRecord docs under “Overwriting default accessors”

http://rails.rubyonrails.org/classes/ActiveRecord/Base.html

–
Rick O.
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com

3

I’m quite interested in the idea of views,
but I’ve never used them,

i imagine that if you create a view called “people_view”,
which is a view on to the people table,

then ActiveRecord will just see this as a normal table?
so

class PersonView < ActiveRecord::Base
set_table_name :people_view
end

will work.

otherwise,
just do it in ruby

class Person < ActiveRecord::Base
def full_name
[first_name, last_name].compact.join(" ")
end
end

is the normal thing to do.

Kevin A. wrote:

I am new to Rails development, having done c++ and other database driven
app development in the past. Often I would create a database view that
would combine, for example, first and last name values into a “virtual”
field called FullName.

I don’t see how to use database views with Rails, so I am thinking that
another way to this would be to define a virtual attribute on the
appropriate class to do the same thing (the derived ActiveRecord or
ApplicationController classes?), but I am unclear where and how this
should be declared.

Can anyone point me in the right direction?

Kevin

4

@Mathew Rudy: Views have nothing to do with the database tables. Views
are just HTML Templates with embedded Ruby to display the data.
so your first idea is totally the wrong direction :wink:

However, your 2nd way is the way to go.

On 18 Jul., 13:29, Matthew R. [email protected]

5

Thorsten wrote:

@Mathew Rudy: Views have nothing to do with the database tables. Views
are just HTML Templates with embedded Ruby to display the data.
so your first idea is totally the wrong direction :wink:

However, your 2nd way is the way to go.

On 18 Jul., 13:29, Matthew R. [email protected]

Thorsten the original poster was asking about database views, not html
templates…

6

Kevin A. wrote the following on 18.07.2007 05:58 :

Can anyone point me in the right direction?

For this particular need, a simple ‘full_name’ method in your model is
probably simpler.
If you need to affect names by full name, you can code a full_name=
method too.

It’s probably better because:

  • much simpler to handle, all your logic is in one place: the model,
  • Ruby is more powerful than pure SQL (ie: your full_name will be easier
    to code and extend),
  • doing it in the model instead of the DB is more flexible, a model has
    access to code (libraries) you can share easily with other parts of your
    application (most likely other models),
  • you don’t have to aggregate data accross rows or join tables to get at
    this data, so doing it in the model can’t be a problem for performance
    (which is not to say that you’ll get better perf using views when joins
    are implicated), in fact accessing the DB only once to instanciate the
    model will yield better performance in your case.

Lionel

7

Sorry, my mistake :stuck_out_tongue:

On 18 Jul., 15:27, Mikkel B. [email protected]

8

class Person < AR::Base

def fullname
first_name + " " + lastname
end
end

p = Person.create(:first_name => “Joe”, :last_name => “Smith”)
p.first_name # “Joe”
p.last_name # “Smith”
p.fullname # “Joe S.”

9

I want to say that this is a most helpful forum! The availability of
quick, knowledgeable and polite assistance is wonderful!

I have been skeptical about Ruby on Rails as a development language, but
I may already be won over… Thanks again for your help (I already have
more questions!).

10

I actually prefer

def fullname
“#{self.first_name} #{self.lastname}”
end

because I don’t get exceptions if someone leaves first_name or last_name
nil. (That and I like scoping my vars, though that’s not always
necessary.)

11

I prefer mine;

def full_name
[first_name, last_name].compact.join(" ")
end

as it doesn’t include any unnecessary whitespace in the event that one
of the names is not defined (or, indeed, both)
Brian H. wrote:

I actually prefer

def fullname
“#{self.first_name} #{self.lastname}”
end

because I don’t get exceptions if someone leaves first_name or last_name
nil. (That and I like scoping my vars, though that’s not always
necessary.)

12

Brian H. wrote the following on 18.07.2007 16:46 :

I actually prefer

def fullname
“#{self.first_name} #{self.lastname}”
end

When I said ‘extend’ I had one use-case in mind, here’s a part of one
librairy I coded:

def fullname
    if firstname.blank? && lastname.blank?
        return _('Unknown (fill your firstname and lastname in)')
    elsif firstname.blank? || lastname.blank?
        # no need for space, one is empty
        return "#{firstname}#{lastname}"
    else
        return "#{firstname} #{lastname}"
    end
end

Notes:

  • _() is from ruby-gettext,
  • the .blank? are Rails specific IIRC,
  • the return are superfluous, I’m in the process of ditching some of
    them where they don’t help readability.

This would be quite difficult to do in a SQL view…

Lionel.

13

On Jul 18, 2007, at 9:55 , Lionel B. wrote:

Brian H. wrote the following on 18.07.2007 16:46 :

I actually prefer

def fullname
“#{self.first_name} #{self.lastname}”
end

  • _() is from ruby-gettext,

I’m surprised that in a localized app you’re using attributes such as
“firstname” and “lastname” :slight_smile:

This would be quite difficult to do in a SQL view…

SELECT CASE WHEN firstname = ‘’ THEN lastname
WHEN lastname = ‘’ THEN firstname
ELSE firstname || ’ ’ || lastname
END AS fullname
FROM …

But I agree it’s easy to handle in the app, and especially for
localizations.

Michael G.
grzm seespotcode net

14

On Jul 18, 2007, at 19:57 , Lionel B. wrote:

I was unaware of cultures where people are named by other means,
care to
point me to them?

Well, for example, Yukihiro M. would have his name order
reversed in Japanese. In that case, what is first depends on the
localization.

Michael G.
grzm seespotcode net

15

Michael G. wrote the following on 19.07.2007 03:21 :

Well, for example, Yukihiro M. would have his name order
reversed in Japanese. In that case, what is first depends on the
localization.

Ok. It seems fortunate for me that I’m still far from adressing the
Japanese market.
The problem is probably a vocabulary one (english isn’t my mother
tongue) is forname/surname more suited?
It seems a migration is not far away…

Lionel.

16

On Jul 18, 2007, at 21:49 , Lionel B. wrote:

tongue) is forname/surname more suited?
Depends on how complicated you want to make it :slight_smile: I tend to go with
given name, family name myself, but that still doesn’t cover all the
variations of names around the world. Though I like surname, the
“fore” in forename also carries the meaning of in front, which has
the same issues as first name. But like I said, even these don’t
cover the full range of human naming schemes.

Michael G.
grzm seespotcode net

17

I love threads like these :slight_smile:

18

Michael G. wrote the following on 19.07.2007 01:59 :

  • _() is from ruby-gettext,

I’m surprised that in a localized app you’re using attributes such as
“firstname” and “lastname” :slight_smile:

I was unaware of cultures where people are named by other means, care to
point me to them?

Lionel.