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 -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. On May 18, 9:54 am, Scott Holland <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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. > > Is there any way I store this structured data in XML or YML so I can > still call: > > asset.category.name etc? > > Thanks! > > Scott > -- > Posted viahttp://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> 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'') -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
http://github.com/binarylogic/settingslogic On May 18, 11:02 am, chewmanfoo <chewman...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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. > > On May 18, 9:54 am, Scott Holland <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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. > > > Is there any way I store this structured data in XML or YML so I can > > still call: > > > asset.category.name etc? > > > Thanks! > > > Scott > > -- > > Posted viahttp://www.ruby-forum.com/. > > > -- > > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Scott Holland 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.> > ScottBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. On May 18, 10:15 am, Tim Shaffer <t...-PGA7PSC7mq/3MY4plGdlAw@public.gmane.org> wrote:> > 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'') > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 18 May 2010 16:28, chewmanfoo <chewmanfoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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". -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. On May 18, 10:35 am, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 18 May 2010 16:28, chewmanfoo <chewman...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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". > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I second Tim''s observation, but wish to add: From a design perspective, a more generic approach that preserves everything you know and love about AR models is to create the following tables/models: Category id name description abbreviation SystemType id category_id name description abbreviation Something like that. You can make SytemType acts_as_list if you like to order them, and categories can acts_as_tree if you want them to be hierarchically related. Knock yourself out. Can be as simple or complex as you wish to make it. Category will have a one-to-many relationship with SystemType. Where you would otherwise be tempted to add a table, instead add a Category record. When adding a new SystemType, you must relate it to a Category. The type system can grow without needing migrations. You can also add static methods to SystemType to return all types for a given category. Let''s say one of those is ''Image'' (denoting an image type), inside SystemType you can do something like this: --- def self.find_all_by_category( category_name ) category = Category.find_by_name category_name if category types = SystemType.find( :all, :conditions => ["category_id = ?", category.id], :order => ''name'' ) # this can be whatever you want to order by # and is optional if you don''t care about ordering return types if types.count > 0 end [] end def method_missing( method, *args, &block ) result = self.find_all_by_category method.to_s return result if result super(method,args,block) end --- Now you can do something like SystemType.Image to return all images. Of course, you may have to follow category naming conventions and/or accommodate for stuff like spaces or capitalization, or avoid the complexities of a method_missing implementation altogether and simply name each category in your SystemType model: def self.images return self.find_by_category ''Image'' end This is perhaps a bit more idiomatic Ruby: SystemType.images. Whatever works for you. The main point is to have one model to store all system types by category. You can order by whatever you want, or not at all, in a standardized way, or extend find_by_category to optionally provide a Proc object that does the sorting logic on a per-call basis. - Bob On Tue, May 18, 2010 at 11:15 AM, Tim Shaffer <tim-PGA7PSC7mq/3MY4plGdlAw@public.gmane.org> wrote:> > 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'') > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. On May 18, 10:46 am, Marnen Laibow-Koser <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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-Koserhttp://www.marnen.org > mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted viahttp://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 18 May 2010 16:41, chewmanfoo <chewmanfoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> if you use a > database to create the list, then you necessarily have to reference > their position get to themNo - 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 18 May 2010 16:58, chewmanfoo <chewmanfoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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"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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
If it''s immutable, then why is it in a database? On May 18, 11:02 am, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 18 May 2010 16:58, chewmanfoo <chewman...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > 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" > > 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. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 18 May 2010 17:07, chewmanfoo <chewmanfoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> If it''s immutable, then why is it in a database?<slaps head in disbelief> well... because I find it hard to web-enable these stone tablets :-/ -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
What I''m saying is, if it''s immutable, then you put it in config/ initializers, not in the database. On May 18, 11:11 am, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 18 May 2010 17:07, chewmanfoo <chewman...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > If it''s immutable, then why is it in a database? > > <slaps head in disbelief> > > well... because I find it hard to web-enable these stone tablets :-/ > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Tue, May 18, 2010 at 10:02 PM, chewmanfoo <chewmanfoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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. > > > On May 18, 9:54 am, Scott Holland <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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. > > > > Is there any way I store this structured data in XML or YML so I can > > still call: > > > > asset.category.name etc? > > > > Thanks! > > > > Scott > > -- > > Posted viahttp://www.ruby-forum.com/. > > > > -- > > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > > For more options, visit this group athttp:// > groups.google.com/group/rubyonrails-talk?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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''} On May 18, 6:28 pm, Scott Holland <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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 > -- > Posted viahttp://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 18 May 2010 17:54, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:>> class Image >> VALID_IMAGE_TYPES = [''png'', ''gif'', ''jpg''] >> end >> > > Good idea.Yes - in my own file_attachment object, I use the same constant! :-) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On May 18, 6:54 pm, Marnen Laibow-Koser <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Sharagoz wrote: > > IMAGE_TYPES = {:1 => ''Photo'', :2 => ''Document'', :3 => ''Print''} > > Not a good idea -- why use :1, :2, :3 instead of actual numbers or > symbolic keys?Not only is it a bad idea, it''s invalid ruby syntax. Integers cant be symbols. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On May 18, 2010, at 1:10 PM, Sharagoz wrote:> On May 18, 6:54 pm, Marnen Laibow-Koser <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: >> Sharagoz wrote: >>> IMAGE_TYPES = {:1 => ''Photo'', :2 => ''Document'', :3 => ''Print''} >> >> Not a good idea -- why use :1, :2, :3 instead of actual numbers or >> symbolic keys? > Not only is it a bad idea, it''s invalid ruby syntax. Integers cant be > symbols.irb> IMAGE_TYPES = { :"1" => ''Photo'', :"2" => ''Document'', :"3" => ''Print'' } => {:"3"=>"Print", :"1"=>"Photo", :"2"=>"Document"} But that''s not really making the idea any better ;-) -Rob Rob Biedenharn http://agileconsultingllc.com Rob-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org http://gaslightsoftware.com rab-/VpnD74mH8+00s0LW7PaslaTQe2KTcn/@public.gmane.org -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.