On Sunday, October 27, 2019 at 11:52:58 AM UTC-4, Ariel Juodziukynas wrote:
>
> 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
>
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).
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)
>
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)
>
On Thursday, September 26, 2019 at 5:03:00 PM UTC-4, Ariel Juodziukynas
wrote:
>
> 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
On Saturday, October 5, 2019 at 1:41:11 AM UTC-4, hasan...@gmail.com wrote:
>
> What's that?
>>>
>>
> It's a gem that will generate a diagram for your database. Follow the
> instructions on the linked page. -- H
>
> --
> OpenPGP:
>
>
> What's that?
>>
>
It's a gem that will generate a diagram for your database. Follow the
instructions on the linked page. -- H
--
OpenPGP:
https://sks-keyservers.net/pks/lookup?op=get=0xFEBAD7FFD041BBA1
If you wish to request my time, please do so using
*bit.ly/hd1AppointmentRequest
On Saturday, October 5, 2019 at 12:49:45 AM UTC-4, hasan...@gmail.com wrote:
>
> [response inline]
>
> On Fri, 4 Oct 2019 at 21:40, fugee ohu >
> wrote:
>
>> how do i get the fields for item_item_properties on the new item form?
>>
>
> Can you please install
[response inline]
On Fri, 4 Oct 2019 at 21:40, fugee ohu 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
--
On Saturday, October 5, 2019 at 12:19:22 AM UTC-4, hasan...@gmail.com wrote:
>
> [response inline]
>
> On Fri, 4 Oct 2019 at 21:08, fugee ohu >
> wrote:
>
>> has_many :item_properties, through: :item_item_properties
>>
>
> Implying that you have a model corresponding to item_item_properties.
[response inline]
On Fri, 4 Oct 2019 at 21:08, fugee ohu 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
On Thursday, September 26, 2019 at 4:28:41 PM UTC-4, hasan...@gmail.com
wrote:
>
> [response inline]
>
> On Thu, 26 Sep 2019 at 13:17, fugee ohu >
> wrote:
>
>> What data type do you suggest for value column?
>>
>
> There were types suggested by the original responder. However, worrying
>
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
On Thursday, September 26, 2019 at 4:53:15 PM UTC-4, M.FURQAN BiN.AMEEN
wrote:
>
> 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
>
> On Fri, Sep 27, 2019, 1:16 AM fugee ohu >
>
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
On Thursday, September 26, 2019 at 4:32:10 PM UTC-4, Ariel Juodziukynas
wrote:
>
> 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
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
On Fri, Sep 27, 2019, 1:16 AM fugee ohu wrote:
>
>
> On Monday, September 16, 2019 at 4:31:29 PM UTC-4, Ariel Juodziukynas
> wrote:
>>
>>
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
[response inline]
On Thu, 26 Sep 2019 at 13:17, fugee ohu 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
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)
>
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)
>
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
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
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 >
> wrote:
>
>> But then a single item will contain many records, one for each property,
>> wouldn't that create too-large-tables?
>>
>
> By the
[response inline]
On Mon, 23 Sep 2019 at 21:32, fugee ohu 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:
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)
>
On Tuesday, September 24, 2019 at 12:15:02 AM UTC-4, hasan...@gmail.com
wrote:
>
> [response inline]
>
> On Mon, 23 Sep 2019 at 21:02, fugee ohu >
> 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
>
On Tuesday, September 24, 2019 at 12:15:02 AM UTC-4, hasan...@gmail.com
wrote:
>
> [response inline]
>
> On Mon, 23 Sep 2019 at 21:02, fugee ohu >
> 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
>
[response inline]
On Mon, 23 Sep 2019 at 21:02, fugee ohu 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
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)
>
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
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
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
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
34 matches
Mail list logo
