ActiveRecord bottom half

[Bill_Walton]

Hi Perry,

Perry Smith wrote:

What I want to do is create a table that has a unique id
and a string which will be the type. The other tables that
type will point to will have the same id and the attributes
for that type. So, the first table may be items and items
could reference people, companies, etc. The key
to people, companies, etc is the same id as for item -- i.e. if you
union all of the sub tables, you will have each id at most one time.

Your description above contains much that we allow Rails and AR to manage for us. One of the key things with Rails is that primary keys are meaningless to us. Only AR cares about them, and we let it take control of them to make it easier for us to focus on the application itself rather than the management of the data the app uses. You'll find it a lot easier to work with Rails, and to get help here too IME, if you can start by answering: "From a user perspective, what problem are you solving? What is it you're trying to allow the user to do with your application?"

I believe, using PostgreSQL's features, this will be easier
to keep consistent. Of course, I may find out that I'm full
of BS.

I haven't used PostgreSQL with Rails, but don't have the impression from seeing OP's posts that it's any easier or harder than any other supported DB with Rails.

But, part of the knowledge I need to gain is how ActiveRecord
goes from the blob of mess that the database returns to an instance
of a particular class.

Depending on exactly what your objective is, you may or may not need to know the above in order to achieve your objective. Probably not. In general, our apps deal in objects, we tell AR how the objects are related, it handles the ORM mapping, and we're happy for it.

If anyone can help me out and tell me where to look,
etc, that would be much appreciated.

I'd start out by trying to regain my "beginner eyes." Will Rogers said "It's not what we don't know that hurts. It's what we know that ain't true." To be successful with Rails, you're probably going to do quite a bit of 'unlearning.' That's just speculation on my part, based on a year and a half of observation / participation here on the list.

There are a number of beginner tutorials out there. With all things Rails, Google is your friend. You may find it too elementary for you, but you might want to start with:
http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html?page=1

hth,
bill

[Bill_Walton]

Hi Perry,

Perry Smith wrote:

The big thing that is frustrating me with the existing
methods is how to do validation. As I said, I can not
get validates_presence_of to work for me in a
polymorphic belongs_to.

It would be easier to help if you posted the SQL script or migration that you're using to create the tables and the related models.

I'm torn between trying to do validation up in Rails
or down in the DB.

We do validations in our models. Rails treats the DB as a simple container. My experience is that that's the only viable option if you want the freedom to change databases.

<snip awaiting more information>

The only thing that PostgreSQL gives me is rules and stored
procedures to do the validation in the DB. I'm not sure but I
think those are not in other DB's.

They're not in some, and they're handled differently in others. It's one of the fundamental ways that database vendors achieve lockin. Being locked in to an open source DB is still being locked in. Not good, IMHO.

To recap, I'm not wanting to go down this path. I just
want to validate the database and keep it valid at all times.

That's not going to be a problem, assuming you're willing to let Rails and AR do their thing, rather than impose a preconceived solution on them.

Post some code.

Best regards,
Bill

[Bill_Walton]

Hi Perry,

Perry Smith wrote:

Please see:

http://www.ruby-forum.com/topic/113189#new

I may have discovered the error of my ways. Instead of
validates_presence_of, should I be using validates_associated ?

What you don't say in your post above is whether or not you're getting the results you expect. If it accomplishes what you're trying to accomplish, use it. Rails typically gives us more than one way to "skin the cat." Without knowing what you're trying to accomplish it's not possible to say whether or not there's an easier / more Railsy way to do it. I assume you've reviewed the documentation on validates_associated at http://api.rubyonrails.org and seen the note re: the potential need to use validates_presence_of on the association itself.

Best regards,
Bill