XML or YML?

Rails
1

Hello,

I’m probably being really dumb but I can never figure this out.

I want to store things like categories, salutations, image type etc etc
but it seems dumb to create a database table for each of these.

Is there any way I store this structured data in XML or YML so I can
still call:

asset.category.name etc?

Thanks!

Scott

2

I’d like to second this request -
I found myself fleshing out a lot of the details of my data base
structure using categories, salutations, image_types etc tables, which
I could then populate via a scaffold, and select in other tables using
a collection select. The problem is, when you want to go back and
alphabetize the categories list, for example, you get the record id’s
changing, and then an object with a category_id of 12 is now pointing
to a different category than it was before (since you reordered the
table), which forces you to create after_save actions to update all
the objects that reference the categories table.

But if categories were in an xml/yml file, then their database table
id would be irrelevant etc.

3

The problem is, when you want to go back and
alphabetize the categories list, for example, you get the record id’s
changing, and then an object with a category_id of 12 is now pointing
to a different category than it was before (since you reordered the
table), which forces you to create after_save actions to update all
the objects that reference the categories table.

What? I think you might be doing it wrong. You don’t need to change
anything in the database to show the categories in alphabetical order:

Category.find(:all, :order => ‘title’)

4
5

No, I know. what i’m caying is, if you do somehow reorder the
categories, then your objects which reference them are all re-
categorized. that’s bad - it’s a dependency that is unnecessary.

6

On 18 May 2010 16:28, chewmanfoo [email protected] wrote:

then your objects which reference them are all re-
categorized. that’s bad - it’s a dependency that is unnecessary.

??

Only if the “somehow” you re-order them by is to change the content of
the object because you assume “id” is “position”.

7

what Scott was asking for originally was a way to enumerate options
without having to reference their position in a list. if you use a
database to create the list, then you necessarily have to reference
their position get to them, but if you define the list with, say, a
yml file, then position is irrelevant. So, you can alter the list at
will without having to worry about the consequences for objects which
reference the list - you just can’t delete an item in the list.

8

chewmanfoo wrote:

what Scott was asking for originally was a way to enumerate options
without having to reference their position in a list. if you use a
database to create the list, then you necessarily have to reference
their position get to them, but if you define the list with, say, a
yml file, then position is irrelevant. So, you can alter the list at
will without having to worry about the consequences for objects which
reference the list - you just can’t delete an item in the list.

Nope, wrong. Primary key is not “position in a list”. Please learn a
bit more about how SQL databases actually work.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

9

Wow ok.

So, the following:

Class Shape < ActiveRecord::Base
attr_accessible :color_id
belongs_to :color
end

Class Color < ActiveRecord::Base
has_many :shapes
end

Now, in the console:

sh = Shape.last
…
sh.color_id
12
sh.color.name
“red”
…
c = Color.find(12)
c.name = “blue”
c.save!
…
sh.color.name
“blue”

Oops! Now, every shape with shape.color_id =12 is now blue. You’ve
changed a Color, but inadvertently changed a Shape as well. That’s
uncomfortable if not bad.

But maybe it’s just me.

10

On 18 May 2010 16:41, chewmanfoo [email protected] wrote:

if you use a
database to create the list, then you necessarily have to reference
their position get to them

No - you reference their “primary key”. This does not equate (unless
you have a very bad approach to DB design) to position.

but if you define the list with, say, a
yml file, then position is irrelevant.

No - again. If you have a yaml data source, you’re probably going to
be storing a string value for the object. Exactly the same as if you’d
stored the string description (assuming the field was called
“description”) of a db-table record. Absolutely no reference to
“position” is given.

So, you can alter the list at
will without having to worry about the consequences for objects which
reference the list - you just can’t delete an item in the list.

If you’re worried about referential integrity, then check for it
before allowing records to be deleted.

I have a strong feeling, Chewmanfoo, that you aren’t grasping some of
the fundamental principles of SQL, and using relational databases to
store representations of objects.

11

Scott H. wrote:

Hello,

I’m probably being really dumb but I can never figure this out.

I want to store things like categories, salutations, image type etc etc
but it seems dumb to create a database table for each of these.

It’s not dumb to put these in the database.

Is there any way I store this structured data in XML or YML so I can
still call:

asset.category.name etc?

Thanks!

YAML might work well here. XML is almost always overkill.

Scott

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

12

On 18 May 2010 16:58, chewmanfoo [email protected] wrote:

has_many :shapes
…
c = Color.find(12)
c.name = “blue”
c.save!
…
sh.color.name
“blue”

Why would you ever change a colour’s name? If it’s blue it’s blue.
It’s immutable; atomic.
It’s a value in a lookup table.

If you want to store the “name” of the colour instead of its id
(because you find yourself often doing hideous things like changing
the values in lookups), then do so; you’ll just have a poor,
inflexible DB.

13

On 18 May 2010 17:07, chewmanfoo [email protected] wrote:

If it’s immutable, then why is it in a database?

well… because I find it hard to web-enable these stone tablets :-/

14

If it’s immutable, then why is it in a database?

15

What I’m saying is, if it’s immutable, then you put it in config/
initializers, not in the database.

16

chewmanfoo wrote:

If it’s immutable, then why is it in a database?

What he’s saying is that it is “immutable” by policy. If you have a
database that stores orders where each order contains an order number
(not a primary key, but rather a number given to a customer), by policy
that order number should never change. If it did you would lose track of
the order.

This has nothing to do with position in the database. Order number is
simply a reference to one specific order. A reference that must be
immutable and atomic.

17

wow, I didn’t expect such a response!

Maybe I should be storing this data in the db like I am at the moment,
it just seem a bit overkill to have a table with:

Image_type
1 => Photo
2 => Document
3 => Print

There must be some way I can define these values in the application
and still have all the associations work?

Thanks

18

You are right, creating a database table for something like this does
feel like overkill. Personally, I often use constants if it’s a very
small amount of data.

class Image
VALID_IMAGE_TYPES = [‘png’, ‘gif’, ‘jpg’]
end

or
IMAGE_TYPES = {:1 => ‘Photo’, :2 => ‘Document’, :3 => ‘Print’}

19

Sharagoz wrote:

You are right, creating a database table for something like this does
feel like overkill. Personally, I often use constants if it’s a very
small amount of data.

class Image
VALID_IMAGE_TYPES = [‘png’, ‘gif’, ‘jpg’]
end

Good idea.

or
IMAGE_TYPES = {:1 => ‘Photo’, :2 => ‘Document’, :3 => ‘Print’}

Not a good idea – why use :1, :2, :3 instead of actual numbers or
symbolic keys?

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

20

On 18 May 2010 17:54, Marnen Laibow-Koser [email protected] wrote:

class Image
VALID_IMAGE_TYPES = [‘png’, ‘gif’, ‘jpg’]
end

Good idea.

Yes - in my own file_attachment object, I use the same constant! :slight_smile: