Rails - Jul 2009 - strategy for storing/accessing custom attributes?

I''m working on a contact management app and 3 of the requirements are:

* the user should be able to add additional custom Contact fields
(e.g. an extra phone number that isnt provided in the std set of
fields)
* the user should be able to name fields with whatever label they want
(e.g. one user might label with "Vacation Phone", another as
"Home
Office Phone"
* the custom data will be typed and grouped so that we know that it''s
text data vs a phone number (for example) and so that we can get the
list of all custom phone numbers or addresses

I''m more concerned with the first req right now regarding storage and
the best way to then access and use this data, but am glad to hear
thoughts on the others as well.

My thought is to have a column in the DB called "custom"
that''s a text
field and then either go with a YAML style or XML for storing the
field label and data.

But, what''s the best way to encapsulate and do things in the model
code to make these attributes accessible from the rest of the app in a
way thatis transparent to those other parts of the app?

Perhaps the serialize method could be helpful:

http://apidock.com/rails/ActiveRecord/Base/serialize/class

Cheers,
Nicholas

On Jul 16, 7:02 pm, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I''m working on a contact management app and 3 of the requirements
are:
>
> * the user should be able to add additional custom Contact fields
> (e.g. an extra phone number that isnt provided in the std set of
> fields)
> * the user should be able to name fields with whatever label they want
> (e.g. one user might label with "Vacation Phone", another as
"Home
> Office Phone"
> * the custom data will be typed and grouped so that we know that
it''s
> text data vs a phone number (for example) and so that we can get the
> list of all custom phone numbers or addresses
>
> I''m more concerned with the first req right now regarding storage
and
> the best way to then access and use this data, but am glad to hear
> thoughts on the others as well.
>
> My thought is to have a column in the DB called "custom"
that''s a text
> field and then either go with a YAML style or XML for storing the
> field label and data.
>
> But, what''s the best way to encapsulate and do things in the model
> code to make these attributes accessible from the rest of the app in a
> way thatis transparent to those other parts of the app?

thx nicholas

I''d thought of using serialize, but decided to just do it as yaml

so, for the  moment, I''m good on my first req

the third req of being able to group/type the custome field data will
either be handled by structuring the yaml or I may split things into
seperate colums for te diff types of data... this may help with
searches a bit

the second req is what''s befuddling me now... with fixed field names,
I can create attr_accessors for each of them and do explicit setter/
getters for each attribute... but having a dynamic list of attributes,
both in count and attr name, I''m not sure how to set that up...

can anybody help with that?

On Jul 16, 6:02 pm, Nicholas Henry
<nicholas.he...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Perhaps the serialize method could be helpful:
>
> http://apidock.com/rails/ActiveRecord/Base/serialize/class
>
> Cheers,
> Nicholas
>
> On Jul 16, 7:02 pm, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I''m working on a contact management app and 3 of the
requirements are:
>
> > * the user should be able to add additional custom Contact fields
> > (e.g. an extra phone number that isnt provided in the std set of
> > fields)
> > * the user should be able to name fields with whatever label they want
> > (e.g. one user might label with "Vacation Phone", another as
"Home
> > Office Phone"
> > * the custom data will be typed and grouped so that we know that
it''s
> > text data vs a phone number (for example) and so that we can get the
> > list of all custom phone numbers or addresses
>
> > I''m more concerned with the first req right now regarding
storage and
> > the best way to then access and use this data, but am glad to hear
> > thoughts on the others as well.
>
> > My thought is to have a column in the DB called "custom"
that''s a text
> > field and then either go with a YAML style or XML for storing the
> > field label and data.
>
> > But, what''s the best way to encapsulate and do things in the
model
> > code to make these attributes accessible from the rest of the app in a
> > way thatis transparent to those other parts of the app?

From the question I guess that you have added multiple "standard"
address and phone fields to the contact record, i.e. you have
something like home_address, work_address, home_phone and work_phone
*columns* in your table, which I think is a bad idea to begin with.
This makes it very ugly to do stuff like ''who has the phone
XXX'' or
who lives in New York etc.
The right way to do it is to have a separate addresses and phones
tables and to have a separate record there for any phone/address you
have for the contact. Then your ''standard'' fields will be just
suggestions in the interface for the ''description'' field of a
relevant
record. i.e. in the database there will be no difference between ''home
address'' and ''my super secret hideaway address'' other
then the
''description'' text.
As an additional benefit this approach will make it practical to break
down the records into subfields, e.g. address, city, zip code,
country. etc. (and it would be absolutely insane to do it while
stuffing all into a single contact record, or you would end up with
literally hundreds of fields)

to make the access ''transparent'' to the rest of the app you
need to
consider 2 things:

since there is no difference between the records you can access them
all the same. i.e.  you have contact.addressess, contact.phone_numbers
etc. you can have custom methods on the associations to do stuff like
contact.addressess["home address"] if you really need it :)


On Jul 17, 2:02 am, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I''m working on a contact management app and 3 of the requirements
are:
>
> * the user should be able to add additional custom Contact fields
> (e.g. an extra phone number that isnt provided in the std set of
> fields)
> * the user should be able to name fields with whatever label they want
> (e.g. one user might label with "Vacation Phone", another as
"Home
> Office Phone"
> * the custom data will be typed and grouped so that we know that
it''s
> text data vs a phone number (for example) and so that we can get the
> list of all custom phone numbers or addresses
>
> I''m more concerned with the first req right now regarding storage
and
> the best way to then access and use this data, but am glad to hear
> thoughts on the others as well.
>
> My thought is to have a column in the DB called "custom"
that''s a text
> field and then either go with a YAML style or XML for storing the
> field label and data.
>
> But, what''s the best way to encapsulate and do things in the model
> code to make these attributes accessible from the rest of the app in a
> way thatis transparent to those other parts of the app?

vitaly, thx for your ideas

I hadnt really considered going the way you suggest, prob due to some
sense that that would make the object model way more complexe for a
Contact (has_many :phone_numbers, has_many :addresses,
has_many :emails, etc)... I kinda like that, though, now that you
suggest it.

2 follow on questions for you (and others):

1) might this be less efficient performance-wise if everything is
scattered across tables?

2) since the req is to let them create any number of arbitrary fields,
it seems like there will be those that wont fit as nicely into the
has_many constructs I outline above... I think I''d have to either
still do this cisutom field column or maybe have something like
has_many :custom_text_fields to put them in... thoughts on that part?

Thx again.

On Jul 21, 12:33 pm, Vitaly Kushner
<vit...-ZoGT8FfVpmtWk0Htik3J/w@public.gmane.org>
wrote:
> From the question I guess that you have added multiple "standard"
> address and phone fields to the contact record, i.e. you have
> something like home_address, work_address, home_phone and work_phone
> *columns* in your table, which I think is a bad idea to begin with.
> This makes it very ugly to do stuff like ''who has the phone
XXX'' or
> who lives in New York etc.
> The right way to do it is to have a separate addresses and phones
> tables and to have a separate record there for any phone/address you
> have for the contact. Then your ''standard'' fields will be
just
> suggestions in the interface for the ''description'' field
of a relevant
> record. i.e. in the database there will be no difference between
''home
> address'' and ''my super secret hideaway address''
other then the
> ''description'' text.
> As an additional benefit this approach will make it practical to break
> down the records into subfields, e.g. address, city, zip code,
> country. etc. (and it would be absolutely insane to do it while
> stuffing all into a single contact record, or you would end up with
> literally hundreds of fields)
>
> to make the access ''transparent'' to the rest of the app
you need to
> consider 2 things:
>
> since there is no difference between the records you can access them
> all the same. i.e.  you have contact.addressess, contact.phone_numbers
> etc. you can have custom methods on the associations to do stuff like
> contact.addressess["home address"] if you really need it :)
>
> On Jul 17, 2:02 am, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I''m working on a contact management app and 3 of the
requirements are:
>
> > * the user should be able to add additional custom Contact fields
> > (e.g. an extra phone number that isnt provided in the std set of
> > fields)
> > * the user should be able to name fields with whatever label they want
> > (e.g. one user might label with "Vacation Phone", another as
"Home
> > Office Phone"
> > * the custom data will be typed and grouped so that we know that
it''s
> > text data vs a phone number (for example) and so that we can get the
> > list of all custom phone numbers or addresses
>
> > I''m more concerned with the first req right now regarding
storage and
> > the best way to then access and use this data, but am glad to hear
> > thoughts on the others as well.
>
> > My thought is to have a column in the DB called "custom"
that''s a text
> > field and then either go with a YAML style or XML for storing the
> > field label and data.
>
> > But, what''s the best way to encapsulate and do things in the
model
> > code to make these attributes accessible from the rest of the app in a
> > way thatis transparent to those other parts of the app?