ActiveRecord flexible columns


#1

I would like to have a table with flexible columns.
For example i have the following table customers:

id
name
email

The user should be able to save other columns to the database as well :

me = Customer.find(10)
me.name = ‘me company’
me.email = ‘removed_email_address@domain.invalid’
me.msn = ‘me1234’ # custom columns
me.birthdate = ‘2005-10-01’ #custom columns

I have seen a idea from :

http://trac.vaillant.ca/store.rb/wiki/DbModelVirtualFields

Anybody else a good idea ?

Daniel


#2

Hi,

I would like to have a table with flexible columns.
For example i have the following table customers:

Watch this project.

http://rubyforge.org/projects/apptrain/

Ciao’


#3

will have a look, but i can only find a gem

Mathieu C. wrote:

Hi,

I would like to have a table with flexible columns.
For example i have the following table customers:

Watch this project.

http://rubyforge.org/projects/apptrain/

Ciao’


#4

I think this is’nt the way to go, you still have to define te fields.
I would like to add custom fields on the fly.
For example i import a cvs file with the some required fields and the
rest is custom

For example there is the following setup :

Table customers
has many Contacts

I would like to make it possible that every customer can have custom
contactfields
(there are some required fields)

daniel wijnands wrote:

will have a look, but i can only find a gem

Mathieu C. wrote:

Hi,

I would like to have a table with flexible columns.
For example i have the following table customers:

Watch this project.

http://rubyforge.org/projects/apptrain/

Ciao’


#5

How about writing a Ruby module that dynamically expands your table when
a
new field is needed with something like:

custom1
custom1name

Initially your table would only have a single custom field. Each user
would
define what it stands for with the custom1name field. Then when a user
requests a second custom field, your module would check to see if it
exists
and if not, update the database to add another custom field and
customname
field (custom2, custom2name). Your rails app could use javascript and
httpxmlrequest to make the whole thing feel very real-time as if the
fields
were there to begin with. Eventually your database will contain enough
custom fields for most users (10?, 20?) and your field addition code
will be
used less frequently.

I have never done this before so there may be some drawbacks, but it
seems
like it might work.

Eden


#6

No i don’t think this will work, for example i have the following
example :

table: customer has_many :contacts
table: contact , belongs_to :customer , table fields = :name and :email

I have a customer 1 that would like to define 3 custom fields for a
contact,
for example :

  • gender , - first_name , -last_name

And another customer would like to add 2 custom fields

  • created_at
  • potential

If would use your method, i would add 5 columns to the contacts table
There can be very much customers and so there can bee very much custom
contact fields
The other customers don’t has a interest in potential or first_name
Also you will have a problem when defining validations , potential can
be a required field for a customer
but not for another

Bases on the virtual fields i now have the following solution wich works
quite nice :

virtual_attributes
virtual_attribute_types
virtual_attributes_values

A customer can define, with a nice interface custom fields for a class

I made a acts_as_free_form plugin for ActiveRecord
that includes all the virtual fields for a class :

asts_as_free_form

This does the following :
Override the method missing
When a method is called for an object contact.gender the method get’s or
sets the value in the virtual_attribute_values
Also it defines a validate for the class wich validates the virtual
fields.

It is also possible to limit the virtual field for a class by an extra
condition :

acts_as_free_form :conditions=>‘customer_id = 1’

Now only virtual-attributes for the customer with id are usable
So a customer can have custom virutal attributes

Oh another thing , all virtual fields get written to a char field, but
on reading and setting the are transformed to the right type, for exampe
:

virutal_field :created_at , type = datetime

contact.craeted_at = Time.today
contact.save , results in a string value in database “2005-10-1
23:23:22”

when reading :

contact = Contact find(1)
contact.created_at.class = Time

The type_casting is as in ActiveRecord itself

I’m thinking of adding a table virtual_attribute_validations to define
rules for validation the virtual attribute, so i can build an nice
webinterface to define validations for an attribute

If anyone is interested in the code , let me now

Eden B. wrote:

How about writing a Ruby module that dynamically expands your table when
a
new field is needed with something like:

custom1
custom1name

Initially your table would only have a single custom field. Each user
would
define what it stands for with the custom1name field. Then when a user
requests a second custom field, your module would check to see if it
exists
and if not, update the database to add another custom field and
customname
field (custom2, custom2name). Your rails app could use javascript and
httpxmlrequest to make the whole thing feel very real-time as if the
fields
were there to begin with. Eventually your database will contain enough
custom fields for most users (10?, 20?) and your field addition code
will be
used less frequently.

I have never done this before so there may be some drawbacks, but it
seems
like it might work.

Eden


#7

Am 29.12.2005 um 10:54 schrieb daniel wijnands:

I made a acts_as_free_form plugin for ActiveRecord
fields.
on reading and setting the are transformed to the right type, for

contact = Contact find(1)
contact.created_at.class = Time

The type_casting is as in ActiveRecord itself

I’m thinking of adding a table virtual_attribute_validations to define
rules for validation the virtual attribute, so i can build an nice
webinterface to define validations for an attribute

If anyone is interested in the code , let me now

i’m interested in the code because i’m working on a related problem.
but: there is acts_as_taggable(1) which behaves much like your
acts_as_free_form. i think it would be valuable to merge your code
with it (just add support for key<->value tags instead of just raw
tag names)…

lorenz

  1. http://dema.ruby.com.br/articles/2005/09/03/tagging-on-steroids-
    with-rails

#8

Will have a look at acts_as_taggible, thanks


#9

I don’t see wy acts_as_taggable is remotely the same.
Acts as taggable adds a handle .tags to an Object.
My acts_as_free_form ads custom methods and settors to an Object
These methods have values.

Acts_as_taggable only defines tags for an object but these tags can’t
have values.

Or am i seeing it all wrong ?


#10

I think tags should be tags, a tag describes an object and shouldn’t
have a value a think
I dont’s see that working, when my code is ready for release you might
give it a try

Best daniel

Lorenz Schori wrote:

Am 29.12.2005 um 12:18 schrieb Daniel W.:

I don’t see wy acts_as_taggable is remotely the same.
Acts as taggable adds a handle .tags to an Object.
My acts_as_free_form ads custom methods and settors to an Object
These methods have values.

Acts_as_taggable only defines tags for an object but these tags can’t
have values.

Or am i seeing it all wrong ?

no, sure it is not the same… i stated this in my previous post:
“just add support for key<->value tags instead of just raw tag names”.

i think the concept of free form attributes / tags is very valuable
for many applications. i’d appreciate it if i only had to include one
of them (DRY):
from acts_as_taggable documentation(1):
photo.tag [ 'wine ‘, ’ vodka’], :clear => true

i’d like to be able to say:
person.tag { ‘AIM’ => ‘000000’, ‘Location’ => ‘Honolulu’ }

your acts_as_freeform might do something like this but i think
merging it into acts_as_taggable would be a valuable option too.

lorenz

  1. http://dema.ruby.com.br/files/taggable/doc/index.html

#11

Am 29.12.2005 um 12:18 schrieb Daniel W.:

I don’t see wy acts_as_taggable is remotely the same.
Acts as taggable adds a handle .tags to an Object.
My acts_as_free_form ads custom methods and settors to an Object
These methods have values.

Acts_as_taggable only defines tags for an object but these tags can’t
have values.

Or am i seeing it all wrong ?

no, sure it is not the same… i stated this in my previous post:
“just add support for key<->value tags instead of just raw tag names”.

i think the concept of free form attributes / tags is very valuable
for many applications. i’d appreciate it if i only had to include one
of them (DRY):
from acts_as_taggable documentation(1):
photo.tag [ 'wine ‘, ’ vodka’], :clear => true

i’d like to be able to say:
person.tag { ‘AIM’ => ‘000000’, ‘Location’ => ‘Honolulu’ }

your acts_as_freeform might do something like this but i think
merging it into acts_as_taggable would be a valuable option too.

lorenz

  1. http://dema.ruby.com.br/files/taggable/doc/index.html