auction site listings table

[fugee ohu]

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

[Ariel Juodziukynas]

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

[Andrew Cranston]

Agreed - relational tables are the way to go here. Only one suggestion I'd make is around semantics, I'd rename auctions to auction_items, and then the join table would need to be auction_item_properties.
I may be misunderstanding, but my thinking is an auction to be the top-level bucket which has properties like a start time, end time, location, membership, lots/items, etc - so it would have many items. 

If each auction is item-specific however, then ignore this comment :)

On Monday, September 16, 2019 at 1:31:29 PM UTC-7, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

[fugee ohu]

On Tuesday, September 17, 2019 at 2:58:21 PM UTC-4, Andrew Cranston wrote:

Agreed - relational tables are the way to go here. Only one suggestion I'd make is around semantics, I'd rename auctions to auction_items, and then the join table would need to be auction_item_properties.
I may be misunderstanding, but my thinking is an auction to be the top-level bucket which has properties like a start time, end time, location, membership, lots/items, etc - so it would have many items. 

If each auction is item-specific however, then ignore this comment :)

On Monday, September 16, 2019 at 1:31:29 PM UTC-7, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if youto at're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

I'm trying  to agree with you but why would an auction have many items?

[fugee ohu]

On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

Where do the values of the properties go? I don't mean the property name

[Hasan Diwan]

[response inline]

On Mon, 23 Sep 2019 at 21:02, fugee ohu <fuge...@gmail.com> wrote:

Where do the values of the properties go? I don't mean the property name

Properties will have an "id" field, referred to as auction_properties.property_id. Under auction_properties, there is a value field. I'd assume it goes there, right, Ariel? -- H

--

OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1

If you wish to request my time, please do so using bit.ly/hd1AppointmentRequest.

Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.

Sent from my mobile device 

Envoye de mon portable

[fugee ohu]

 Yes, sorry I see, that's the value column in auction_properties

[fugee ohu]

On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

But then a single item will contain many records, one for each property, wouldn't that create too-large-tables?

[Hasan Diwan]

[response inline]

On Mon, 23 Sep 2019 at 21:32, fugee ohu <fuge...@gmail.com> wrote:

But then a single item will contain many records, one for each property, wouldn't that create too-large-tables?

By the time that becomes a problem, you'll have bigger things to worry about it, mate. -- H 

[fugee ohu]

 I can't make up my mind First, there's countless types of items Next they may use the category in deciding which form to load We haven't take categories into account  yet in this discussion

[Ariel Juodziukynas]

Another option (if your database accepts it, like postgres or newer MySQL versions) is to use a column with JSON or JSONB type. You could have a json object with all property/value pairs. I'm not sure about performance, indexing, etc on JSON columns though.

I'm not sure what are the categories you are talking about now, you mean the "auction type"?

You'll have to have many many millions of auctions in order to make the auction_properties tables too large (if your ID is an int, you have 2,000 MILLION ids to use, if you use bigint I don't even know that number, you'll need really good indexes though haha), and even if you ever get near some critical situation you could split table by auction type or something like that. I doubt it's something you have to worry about right now, you'll have a lot of more important things to improve before reaching that.

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/63f7e9f5-eb9a-4618-8ed9-d1f78f3a05b8%40googlegroups.com.

[fugee ohu]

On Tuesday, September 24, 2019 at 7:18:11 PM UTC-4, Ariel Juodziukynas wrote:

Another option (if your database accepts it, like postgres or newer MySQL versions) is to use a column with JSON or JSONB type. You could have a json object with all property/value pairs. I'm not sure about performance, indexing, etc on JSON columns though.

I'm not sure what are the categories you are talking about now, you mean the "auction type"?

You'll have to have many many millions of auctions in order to make the auction_properties tables too large (if your ID is an int, you have 2,000 MILLION ids to use, if you use bigint I don't even know that number, you'll need really good indexes though haha), and even if you ever get near some critical situation you could split table by auction type or something like that. I doubt it's something you have to worry about right now, you'll have a lot of more important things to improve before reaching that.

El mar., 24 sept. 2019 a las 19:19, fugee ohu (<fuge...@gmail.com>) escribió:

On Tuesday, September 24, 2019 at 12:37:37 AM UTC-4, hasan...@gmail.com wrote:

[response inline]

On Mon, 23 Sep 2019 at 21:32, fugee ohu <fuge...@gmail.com> wrote:

But then a single item will contain many records, one for each property, wouldn't that create too-large-tables?

By the time that becomes a problem, you'll have bigger things to worry about it, mate. -- H 

--

OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1

If you wish to request my time, please do so using bit.ly/hd1AppointmentRequest.

Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.

Sent from my mobile devicet t

Envoye de mon portable

 I can't make up my mind First, there's countless types of items Next they may use the category in deciding which form to load We haven't take categories into account  yet in this discussion

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/63f7e9f5-eb9a-4618-8ed9-d1f78f3a05b8%40googlegroups.com.

When you sell something on ebay there's no multiple choice of item type to sell, they figure out the type of item and the category from the title you provide but then ask you to confirm or change the category At this primitive stage I was thinking of adding an intermediate page to the new action to allow the user to select the type or category and then when they submit that page the relevant form will be on the next page There's such a thing as fallback also so I think I should build a rest framework first, I don't know

[fugee ohu]

On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

Could I give the join table different value fields for different data types llike text_value, date_value, string_value, ...

[fugee ohu]

On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

What data type do you suggest for value column

[Hasan Diwan]

[response inline]

On Thu, 26 Sep 2019 at 13:17, fugee ohu <fuge...@gmail.com> wrote:

What data type do you suggest for value column?

There were types suggested by the original responder. However, worrying about column types is an instance of premature optimization. 

Get the basic site working, and then optimize, once you have determined your performance needs. -- H

--

OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1

If you wish to request my time, please do so using bit.ly/hd1AppointmentRequest.

Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.

Sent from my mobile device

Envoye de mon portable

[Ariel Juodziukynas]

The easiest but too big is a text columns so you can use activerecord' serialization of attributes to save anything you want on a text field and activerecord will handle casting.

You could use a string column if you know your values won't be too big (VARCHAR(255)) and you know what types you want to accept and handle serialization yourself like:

    def value=(something)
      val = if value.is_a?(Integer)

              "integer:#{something}"

            elsif value.is_a?(String)

              "string:#{something}"

            elsif value.is_a?(Date)

              "date:#{something}

            # etc...

      write_attribute(:value, val)

    end

    def value

      type, val = read_attribute(:value).split(':')

      case type

      when "integer" then val.to_i

      when "string" then val

      when "date" then Date.parse(val)

      etc...

    end

           

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e74aaf6b-b9e1-4847-a6d3-3120829fa3bc%40googlegroups.com.

[M.FURQAN BiN.AMEEN]

I have a complete project as like in ruby on rail with same tables name you can contact with me further on my email 

Best Regards:
MUHAMMAD FURQAN

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/02ff8e61-7024-4b21-a8b0-680507d8cb69%40googlegroups.com.

[fugee ohu]

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e74aaf6b-b9e1-4847-a6d3-3120829fa3bc%40googlegroups.com.

 If I'm using a string column then whatever value is put in it is a string, so I don't understand all these "'if value.is_a?" conditions

[Ariel Juodziukynas]

You were asking a way to store different values, I thought you wanted to preserve the type (so you can distinguish 1 from "1" when you read the record).

If you think strings are enough for your requirements just use a string column, if you want to use one column to store values but preserve the original type you have to serialize the value somehow (that's the is_a?... when serializing and the case when casting).

Another option is to use two columns: one for the stringified value and one for the original type so you can parse that again.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/93726aa7-2667-4f3b-b27c-6d19d5e5f368%40googlegroups.com.

[fugee ohu]

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/02ff8e61-7024-4b21-a8b0-680507d8cb69%40googlegroups.com.

whats your email

[fugee ohu]

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/63f7e9f5-eb9a-4618-8ed9-d1f78f3a05b8%40googlegroups.com.

When I create a new item it doesn't have any properties yet so trying to place a form field returns this error

undefined method `year' for #<Item:0x007fad724a6f38>
year is one of the properties i created in the item_properties table

[fugee ohu]

 has_many :item_properties, through: :item_item_properties
 how can i put fields for item_properties on a new item form

for item_type="Books" I have a property called year

it's the first iteration the loop below comes across

  <% ItemProperty.where(item_type: params[:item_type]).each do |ip| %>
      <div class="field">
        <%= f.label "#{ip.name}" %>
        <%= f.text_area "#{ip.name}".downcase.to_sym %>
      </div>
  <% end %>
and returns this error:

[Hasan Diwan]

[response inline]

On Fri, 4 Oct 2019 at 21:08, fugee ohu <fuge...@gmail.com> wrote:

 has_many :item_properties, through: :item_item_properties

Implying that you have a model corresponding to item_item_properties. You can add fields to it through the relevant migration or using the migration convenience generator.  -- H

[fugee ohu]

I'm creating a new item passing in item_type in my get request to the item controller new action

item_properties has the item_type and name fields

item_item_properties has the item_id and text_value fields

how do i get the fields for item_item_properties on the new item form?

[Hasan Diwan]

[response inline]

On Fri, 4 Oct 2019 at 21:40, fugee ohu <fuge...@gmail.com> wrote:

how do i get the fields for item_item_properties on the new item form?

Can you please install https://github.com/voormedia/rails-erd, run the generator, put the resulting image on imgur.com, and point me to it? -- H

--

OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1

If you wish to request my time, please do so using bit.ly/hd1AppointmentRequest.

Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.

Sent from my mobile device

Envoye de mon portable

[fugee ohu]

What's that?

[Hasan Diwan]

What's that? 

It's a gem that will generate a diagram for your database. Follow the instructions on the linked page. -- H

[fugee ohu]

No thanks

[fugee ohu]

On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

Normally when you submit a form it's for a single record but each item is going to have many item_item_properties and each of them in turn have to be presented as a form field with the label coming from item_property.name and the field being :text_value (a text data type field) How am I going to do that? I can't just place fields for different records alongside each other on a singe form

[fugee ohu]

On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas wrote:

Personally, I would do this:

auctions table

(with the basic shared information of all auctions and an "auction type"))

properties table

property_name (like network, carrier, publisher, etc)

auction_type (like cellphone, book, etc)

auctions_properties

auction_id

property_id

value

That way you can have any number of auction types with any number of specific properties with just 3 tables.

Note that the "value" column would be some string variation (VARCHAR, CHAR, TEXT, etc) depending on your needs, maybe you want to redesign it a little if you want to store different types. Like if you want to store an integer (and retrieve an integer) you'll have to save the original type and reparse it (you could use serialization but that requires a TEXT column and maybe you can't use that many space)

El lun., 16 sept. 2019 a las 17:19, fugee ohu (<fuge...@gmail.com>) escribió:

I was looking at some auction projects that use a single listings table for all auctions but I know on auction sites the form will be different for different types of items like if you're selling a cell phone there'll be a form field for network, carrier, whatever and if you're selling a book there'll be form fields for publisher, year of publication,  so they would have separate tables I assume for books, cell phones, etc? Then how would they treat them all as one?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/512f8b73-e3a4-4e74-95e7-4281e7b54821%40googlegroups.com.

How would I collect all the auction_propertes fields on a single form since they all represent additional records in the auction_properties table

[Ariel Juodziukynas]

Read about the `fields_for` helper on actionview and the `accepts_nested_attributes_for` macro on activerecord to handle nested forms (fields_for to create the form, accepts_nested_attributes_for so activerecord handles the associated objects creation).

https://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-fields_for

https://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html#method-i-accepts_nested_attributes_for

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/fad5e82f-223a-456f-af18-d1e42529b3f0%40googlegroups.com.

[fugee ohu]

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/fad5e82f-223a-456f-af18-d1e42529b3f0%40googlegroups.com.

I don't know, it seems this comes down to one form for multiple records being inserted into the auction_properties table