Has anyone tried to use GUIDs instead of auto-increment primary keys with ActiveRecord? Would it be difficult to adapt AR to work with that? Also, I find that GUIDs sometimes are better primary keys because they are DBMS-independent and more portable if you have to transfer data between different databases. So, besides performance and PK uglyness, what would be other disadvantages of using GUIDs as primary keys? Best regards, Demetrius
> Also, I find that GUIDs sometimes are better primary keys because they > are DBMS-independent and more portable if you have to transfer data > between different databases.So you mean having a GUID table and using that as a primary key generator? You''d have to have some storage to make sure they''re unique. I''m not aware of any DBMS that doesn''t support some form of auto-increment primary key, either through series or an auto increment type. You''ll have to rewrite the SQL, but moving data should be easy enough if your data types are portable. -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
On Apr 6, 2005 5:33 PM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote:> You don''t need a GUID table to store GUIDs, by definition they are > globally unique. It depends on the algoroithm you use, but the one MS > publishes through COM interfaces and the SQL functions are promised to > be unique for around 4 billion years IIRC. They are created with > combinations of MAC address, system time and certain highly variable > system states, to pretty much guarantee uniqueness even if you have > anomolies such as incorrect system clocks or a duplicate MAC address (I > do not think this occurs much if ever anymore even with the cheapest > vendors, and also dont think it will use a LAA).You still need to track them. It may be a 1 in 4 billion year chance, but the chance is still there. In an application that has to be reliable you just can''t take the risk of an unchecked collision.> GUIDs have performance problems in many applications. Not only are they > are a much larger number of bytes to index/store/compare, but with a > sequence and a clustered key, your data is grouped sequentially which > optimizes many applications. With GUIDs you are more likely to see > pseudo-random distributions of data, which isn''t likely to be helpful > (it may or may not hurt you much).Most DBMS are optimised for sequential primary keys. I know Oracle assigns a GUID to every row which is apparently really fast to find - faster than a PK search - but that''s a DBMS thing. -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
> > Also, I find that GUIDs sometimes are better primary keys because they > > are DBMS-independent and more portable if you have to transfer data > > between different databases. > > So you mean having a GUID table and using that as a primary key > generator? You''d have to have some storage to make sure they''re > unique. > > I''m not aware of any DBMS that doesn''t support some form of > auto-increment primary key, either through series or an auto increment > type. You''ll have to rewrite the SQL, but moving data should be easy > enough if your data types are portable.No, I don''t think he means to have a table with pre-generated GUIDs. Rather when the insert is performed, AR would generate the new GUID. Or possibly having the SQL language of the current DB do the generation. For example, in TSQL you just call NEWID(), and will receive a new GUID. What he''s saying about portability has more to do with running a multi-master DB configuration I believe. While most RDBMSs support some form of incremental integer, in a multi-master scenario you then have to worry about having collisions with the generated sequences. With the GUID being unique, you don''t have to worry about those issues when you go to replicate changes. Steve
I''m not a DB expert, but even if AR generates the GUID, wouldn''t it still need to check every table in the database to make sure it doesn''t already exist? Otherwise, you have a chance (however small) of a collission. Due to the overheads involved in checking every table it would seem that the best way is to keep a separate list of all pre-generated GUIDs to check against. So it would seem that you can''t get away from this. Let me know if I''m wrong - It''s an interesting problem. Ben On Apr 6, 2005 4:05 PM, Steve V <ruby-ChEX1j9zMF7JbC0vcoRRxNBPR1lH4CV8@public.gmane.org> wrote:> No, I don''t think he means to have a table with pre-generated GUIDs. Rather > when the insert is performed, AR would generate the new GUID. Or possibly > having the SQL language of the current DB do the generation. For example, in > TSQL you just call NEWID(), and will receive a new GUID.
> You still need to track them. It may be a 1 in 4 billion year chance, > but the chance is still there. In an application that has to be > reliable you just can''t take the risk of an unchecked collision.I don''t think that''s necessarily true. If the risk of a collision is sufficiently low you can ignore it. For example, there is a small chance that a cosmic ray striking your hard drive will change a bit on the drive, corrupting your primary key - are you worried about that? There are many extremely unlikely events that you don''t worry about in a RDBMS - so why worry about a GUIID key collision? Hadley
Juraci Krohling Costa
2005-Apr-06 14:08 UTC
Re: AR: GUID vs. auto-increment as primary key
Hi, Using the Hibernate example: it gives you some options on the PK generation (table sequence, database builtin generator, hibernate generator or custom generator). The "recommended" one is to use the "hibernate generator", so you can keep away from database dependency. Its usually an ugly ID, but I''m sure it won''t repeat too soon :-) I don''t know what database doesn''t supports auto-increment style, but letting the ORM/AR framework to generate the PK gives (to me, at least) a little sensation that its easy to change the DBMS, so, I can just move the data along the DBMS and all relationships are kept. I''m not sure, but I think that MSSQL doesn''t support to set the ID if you are using the identity feature. So, something like this won''t work if your table is empty (or the next id isn''t 1000): insert into mytable (id) values (1000) So, why to worry w/ database issues? :-) Actually, if (in future) rails supports guid''s, I''ll use it always (err... ok, maybe ;-) ). But the current scheme is fine to me, since I won''t use another DBMS than MySQL (or PostgreSQL). regards, juca On Apr 6, 2005 10:32 AM, Ben Myles <ben.myles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I''m not a DB expert, but even if AR generates the GUID, wouldn''t it > still need to check every table in the database to make sure it > doesn''t already exist? Otherwise, you have a chance (however small) of > a collission. > > Due to the overheads involved in checking every table it would seem > that the best way is to keep a separate list of all pre-generated > GUIDs to check against. So it would seem that you can''t get away from > this. > > Let me know if I''m wrong - It''s an interesting problem. > > Ben > > On Apr 6, 2005 4:05 PM, Steve V <ruby-ChEX1j9zMF7JbC0vcoRRxNBPR1lH4CV8@public.gmane.org> wrote: > > No, I don''t think he means to have a table with pre-generated GUIDs. > Rather > > when the insert is performed, AR would generate the new GUID. Or > possibly > > having the SQL language of the current DB do the generation. For > example, in > > TSQL you just call NEWID(), and will receive a new GUID. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa http://jkcosta.info _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Juraci Krohling Costa
2005-Apr-06 14:13 UTC
Re: AR: GUID vs. auto-increment as primary key
Ah, I forget to say how hibernate generates the id =D This is the options that Hibernate gives to the developer: http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-id And this is how the UUID is implemented: <excerpt> 5.1.4.3 <http://5.1.4.3>. UUID Algorithm The UUIDs contain: IP address, startup time of the JVM (accurate to a quarter second), system time and a counter value (unique within the JVM). It''s not possible to obtain a MAC address or memory address from Java code, so this is the best we can do without using JNI. Don''t try to use uuid.string in PostgreSQL. </excerpt> So, its virtually impossible to repeat ;-) regards, juca On Apr 6, 2005 11:08 AM, Juraci Krohling Costa <partenon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi, > > Using the Hibernate example: it gives you some options on the PK > generation (table sequence, database builtin generator, hibernate generator > or custom generator). The "recommended" one is to use the "hibernate > generator", so you can keep away from database dependency. Its usually an > ugly ID, but I''m sure it won''t repeat too soon :-) > > I don''t know what database doesn''t supports auto-increment style, but > letting the ORM/AR framework to generate the PK gives (to me, at least) a > little sensation that its easy to change the DBMS, so, I can just move the > data along the DBMS and all relationships are kept. I''m not sure, but I > think that MSSQL doesn''t support to set the ID if you are using the identity > feature. So, something like this won''t work if your table is empty (or the > next id isn''t 1000): > > insert into mytable (id) values (1000) > > So, why to worry w/ database issues? :-) > > Actually, if (in future) rails supports guid''s, I''ll use it always (err... > ok, maybe ;-) ). But the current scheme is fine to me, since I won''t use > another DBMS than MySQL (or PostgreSQL). > > regards, > juca > > On Apr 6, 2005 10:32 AM, Ben Myles <ben.myles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > I''m not a DB expert, but even if AR generates the GUID, wouldn''t it > > still need to check every table in the database to make sure it > > doesn''t already exist? Otherwise, you have a chance (however small) of > > a collission. > > > > Due to the overheads involved in checking every table it would seem > > that the best way is to keep a separate list of all pre-generated > > GUIDs to check against. So it would seem that you can''t get away from > > this. > > > > Let me know if I''m wrong - It''s an interesting problem. > > > > Ben > > > > On Apr 6, 2005 4:05 PM, Steve V <ruby-ChEX1j9zMF7JbC0vcoRRxNBPR1lH4CV8@public.gmane.org> wrote: > > > No, I don''t think he means to have a table with pre-generated GUIDs. > > Rather > > > when the insert is performed, AR would generate the new GUID. Or > > possibly > > > having the SQL language of the current DB do the generation. For > > example, in > > > TSQL you just call NEWID(), and will receive a new GUID. > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > -- > juraci krohling costa > http://jkcosta.info >-- juraci krohling costa http://jkcosta.info _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Heya :)> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Ben Myles > Sent: Wednesday, April 06, 2005 9:32 AM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] AR: GUID vs. auto-increment as primary key > > I''m not a DB expert, but even if AR generates the GUID, wouldn''t it > still need to check every table in the database to make sure it > doesn''t already exist? Otherwise, you have a chance (however small) of > a collission.On any given machine, as long as the clock keeps moving forward in time the chances of a collision are effectively nil. At least they are so small that you can treat the situation as a form of system error like a dick corruption. Across multiple machines with unique MAC addresses, the chances of inter-machine collision ARE nil. Soulhuntre ---------- http://www.girl2.com - my girls http://www.the-estate.com - my legacy http://wiki.thegreybook.com - my project http://weblog.soulhuntre.com - my thoughts
> I''m not a DB expert, but even if AR generates the GUID, wouldn''t it > still need to check every table in the database to make sure it > doesn''t already exist? Otherwise, you have a chance (however small) of > a collission. > > Due to the overheads involved in checking every table it would seem > that the best way is to keep a separate list of all pre-generated > GUIDs to check against. So it would seem that you can''t get away from > this. > > Let me know if I''m wrong - It''s an interesting problem.No, there wouldn''t be a need to check all tables. If you think about an identity field, it is not unique for every table. Just the one table you''re working with. GUIDs have such a small chance of duplicating, that checking to make sure the new value won''t be a duplicate is more or less overkill. Could that 1 in 2^128 happen tomorrow? Yes. If it does, then the DB will reject the duplicate key, and the process can try to insert the data again. Steve
> On any given machine, as long as the clock keeps moving forward in time the > chances of a collision are effectively nil. At least they are so small that > you can treat the situation as a form of system error like a dick > corruption.Can that type of corruption be treated with medication? :-D (sorry, couldn''t resist) ---------- Scanned for viruses by ClamAV
Heya :)> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Kevin Williams > Sent: Wednesday, April 06, 2005 2:45 PM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] AR: GUID vs. auto-increment as primary key > > > On any given machine, as long as the clock keeps moving forward in time > the > > chances of a collision are effectively nil. At least they are so small > that > > you can treat the situation as a form of system error like a dick > > corruption. > > Can that type of corruption be treated with medication? :-DOops :) My apologies to the list.... I must have been thinking too deeply about randomization seeds :) Soulhuntre ---------- http://www.girl2.com - my girls http://www.the-estate.com - my legacy http://wiki.thegreybook.com - my project http://weblog.soulhuntre.com - my thoughts
On Apr 7, 2005 2:08 AM, Juraci Krohling Costa <partenon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > Using the Hibernate example: it gives you some options on the PK generation > (table sequence, database builtin generator, hibernate generator or custom > generator). The "recommended" one is to use the "hibernate generator", so > you can keep away from database dependency. Its usually an ugly ID, but I''m > sure it won''t repeat too soon :-) > > I don''t know what database doesn''t supports auto-increment style, but > letting the ORM/AR framework to generate the PK gives (to me, at least) a > little sensation that its easy to change the DBMS, so, I can just move the > data along the DBMS and all relationships are kept. I''m not sure, but I > think that MSSQL doesn''t support to set the ID if you are using the identity > feature. So, something like this won''t work if your table is empty (or the > next id isn''t 1000): > > insert into mytable (id) values (1000)Really? I''m not a sql server expert, but the other databases I''ve dealt with (Oracle, pgsql, mysql and sybase ase) just use the ''auto generated'' stuff as the ''default''. If you specify your own values it''ll still work. There are two problems I see with GUIDs. 1) Why build something for the extremely rare scenarios? We move large amounts of data at work, just drop your constraints, load the data then reapply the constraints. 2) They''re slow. 128 bit char keys are slower than (32|64) bit integer keys. 1/2 as much storage and *guaranteed* uniqueness. Win Win. Plus, it''s faster to compare two integers than two strings. While hibernate supports uuid.hex mappings, Gavin & Christian''s book (hibernate in action) doesn''t recommend them.> So, why to worry w/ database issues? :-) > > Actually, if (in future) rails supports guid''s, I''ll use it always (err... > ok, maybe ;-) ). But the current scheme is fine to me, since I won''t use > another DBMS than MySQL (or PostgreSQL). > > regards, > juca > > > On Apr 6, 2005 10:32 AM, Ben Myles <ben.myles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I''m not a DB expert, but even if AR generates the GUID, wouldn''t it > > still need to check every table in the database to make sure it > > doesn''t already exist? Otherwise, you have a chance (however small) of > > a collission. > > > > Due to the overheads involved in checking every table it would seem > > that the best way is to keep a separate list of all pre-generated > > GUIDs to check against. So it would seem that you can''t get away from > > this. > > > > Let me know if I''m wrong - It''s an interesting problem. > > > > Ben > > > > On Apr 6, 2005 4:05 PM, Steve V <ruby-ChEX1j9zMF7JbC0vcoRRxNBPR1lH4CV8@public.gmane.org> wrote: > > > No, I don''t think he means to have a table with pre-generated GUIDs. > Rather > > > when the insert is performed, AR would generate the new GUID. Or > possibly > > > having the SQL language of the current DB do the generation. For > example, in > > > TSQL you just call NEWID(), and will receive a new GUID. > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > -- > juraci krohling costa > http://jkcosta.info > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- Cheers Koz
Steve V wrote:> No, I don''t think he means to have a table with pre-generated GUIDs. Rather > when the insert is performed, AR would generate the new GUID. Or possibly > having the SQL language of the current DB do the generation. For example, in > TSQL you just call NEWID(), and will receive a new GUID.Exactly. I would like if AR would generate in a DBMS-independent way. As for concerns on GUID collision, there are none, this is fairy tale. Even a pretty basic algorithm based on hashing the system clock together with a random number is completely safe for 99.99999% of the cases.> What he''s saying about portability has more to do with running a > multi-master DB configuration I believe. While most RDBMSs support some form > of incremental integer, in a multi-master scenario you then have to worry > about having collisions with the generated sequences. With the GUID being > unique, you don''t have to worry about those issues when you go to replicate > changes.Right on the mark again. That''s the kind of scenario that it hurts to have auto-increment PKs. For instance, I have a .NET web app that uses 3 different dbs with pratically the same schema. Different kinds of users access each db and from time to time we have to copy data between them (the app has a complex workflow). Since we have many master-detail relationships within each db, it''s really painful to copy data between them because when we insert data coming from one db, it already has its PKs defined and they are used also as foreign keys in one-to-many relations, so, in order to insert the data in the other db, we have to generate new PKs and update all FKs where the original PKs were used. It''s a painful process! I wish I had taken the right decision at the time we designed the app and that would be to use GUIDs as PKs, definately the better choice in this case. cheers, Dema
hadley wickham wrote:> > You still need to track them. It may be a 1 in 4 billion > year chance, > > but the chance is still there. In an application that has to be > > reliable you just can''t take the risk of an unchecked collision. > > I don''t think that''s necessarily true. If the risk of a > collision is sufficiently low you can ignore it. For > example, there is a small chance that a cosmic ray striking > your hard drive will change a bit on the drive, corrupting > your primary key - are you worried about that? > There are many extremely unlikely events that you don''t worry > about in a RDBMS - so why worry about a GUIID key collision?The odds of a GUID collision go right up if you generate more than a million of them on the same day on the same PC. In my experience, the odds of there being at least one collision under those conditions are about 50/50. Adelle.
Juraci Krohling Costa
2005-Apr-07 01:53 UTC
Re: AR: GUID vs. auto-increment as primary key
> > Really? I''m not a sql server expert, but the other databases I''ve > dealt with (Oracle, pgsql, mysql and sybase ase) just use the ''auto > generated'' stuff as the ''default''. If you specify your own values > it''ll still work. >Nah, not really. I''m not sure. I just remember that I have this kind of problem a long time ago, and don''t remember exactly what DBMS I was using. Or, maybe, was just a nightmare :-) There are two problems I see with GUIDs.> > 1) Why build something for the extremely rare scenarios? > > We move large amounts of data at work, just drop your constraints, > load the data then reapply the constraints. > >Agreed. If this is the only scenario that GUID is useful, then lets keep it far away from Rails. GUID evil =) 2) They''re slow.> > 128 bit char keys are slower than (32|64) bit integer keys. 1/2 as > much storage and *guaranteed* uniqueness. Win Win. Plus, it''s > faster to compare two integers than two strings. >C''mon, its not a huge difference (maybe, some milliseconds), but yes, its faster to work w/ integers than strings. While hibernate supports uuid.hex mappings, Gavin & Christian''s book> (hibernate in action) doesn''t recommend them. >w00t =D When I started to use hibernate, I read the documentation from top to bottom, and I was pretty sure that the UUID was the recommended. Reading today, just to confirm, I found this: <excerpt url=" http://www.hibernate.org/hib_docs/reference/en/html/quickstart.html"> We use the UUID generator (only recommended for testing, as integer surrogate keys generated by the database should be prefered) and also specify the column CAT_ID of the table CAT for the Hibernate generated identifier value (as a primary key of the table) </excerpt> I''ll change all systems to use integers NOW :-) -- As I said in another email, in another thread (java people wants to blablabla), I''m not planning to use Rails on big applications, that requires the same data in N db servers, but I still think that having more then one choice for advanced users is not a pain. I don''t think that implementing *this* feature is a complex task, nor will cause an extreme overhead. regards, juca On Apr 6, 2005 8:26 PM, Michael Koziarski <koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On Apr 7, 2005 2:08 AM, Juraci Krohling Costa <partenon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hi, > > > > Using the Hibernate example: it gives you some options on the PK > generation > > (table sequence, database builtin generator, hibernate generator or > custom > > generator). The "recommended" one is to use the "hibernate generator", > so > > you can keep away from database dependency. Its usually an ugly ID, but > I''m > > sure it won''t repeat too soon :-) > > > > I don''t know what database doesn''t supports auto-increment style, but > > letting the ORM/AR framework to generate the PK gives (to me, at least) > a > > little sensation that its easy to change the DBMS, so, I can just move > the > > data along the DBMS and all relationships are kept. I''m not sure, but I > > think that MSSQL doesn''t support to set the ID if you are using the > identity > > feature. So, something like this won''t work if your table is empty (or > the > > next id isn''t 1000): > > > > insert into mytable (id) values (1000) > > Really? I''m not a sql server expert, but the other databases I''ve > dealt with (Oracle, pgsql, mysql and sybase ase) just use the ''auto > generated'' stuff as the ''default''. If you specify your own values > it''ll still work. > > There are two problems I see with GUIDs. > > 1) Why build something for the extremely rare scenarios? > > We move large amounts of data at work, just drop your constraints, > load the data then reapply the constraints. > > 2) They''re slow. > > 128 bit char keys are slower than (32|64) bit integer keys. 1/2 as > much storage and *guaranteed* uniqueness. Win Win. Plus, it''s > faster to compare two integers than two strings. > > While hibernate supports uuid.hex mappings, Gavin & Christian''s book > (hibernate in action) doesn''t recommend them. > > > So, why to worry w/ database issues? :-) > > > > Actually, if (in future) rails supports guid''s, I''ll use it always > (err... > > ok, maybe ;-) ). But the current scheme is fine to me, since I won''t use > > another DBMS than MySQL (or PostgreSQL). > > > > regards, > > juca > > > > > > On Apr 6, 2005 10:32 AM, Ben Myles <ben.myles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > I''m not a DB expert, but even if AR generates the GUID, wouldn''t it > > > still need to check every table in the database to make sure it > > > doesn''t already exist? Otherwise, you have a chance (however small) of > > > a collission. > > > > > > Due to the overheads involved in checking every table it would seem > > > that the best way is to keep a separate list of all pre-generated > > > GUIDs to check against. So it would seem that you can''t get away from > > > this. > > > > > > Let me know if I''m wrong - It''s an interesting problem. > > > > > > Ben > > > > > > On Apr 6, 2005 4:05 PM, Steve V <ruby-ChEX1j9zMF7JbC0vcoRRxNBPR1lH4CV8@public.gmane.org> wrote: > > > > No, I don''t think he means to have a table with pre-generated GUIDs. > > Rather > > > > when the insert is performed, AR would generate the new GUID. Or > > possibly > > > > having the SQL language of the current DB do the generation. For > > example, in > > > > TSQL you just call NEWID(), and will receive a new GUID. > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > -- > > juraci krohling costa > > http://jkcosta.info > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > -- > Cheers > > Koz >-- juraci krohling costa http://jkcosta.info _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails