Facebooker talk - Nov 2008 - Overriding id with facebook_id???

I am new to rails, and was wondering if there would be unknown consequences
for setting the user tables primary key to being the facebook_id of a user.
I have implemented this funcionality, and everything is working fine.  All
associations etc.  What are the risks if there are any of overridding the id
with facebook_id?  Why would I not want to do this?  I did this because, it
seems easier to look up a user by their facebook id rather than their id to
get their facebook id in associated table.  Meaning if I have an association
with a user has_many comments, and the comments has a user_id column.  I
think it is easiers looking up things with facebook_ids rather than ids, as
these can get confusing.  just one less thing to worry about.

Does it matter what the order of insertions to the database for creating new
Users?

Any insight would be wonderful.

Graciously,

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/facebooker-talk/attachments/20081111/f4ee855a/attachment.html>

On Nov 11, 2008, at 4:36 AM, Joseph Durden wrote:
> I am new to rails, and was wondering if there would be unknown  
> consequences for setting the user tables primary key to being the  
> facebook_id of a user.  I have implemented this funcionality, and  
> everything is working fine.  All associations etc.  What are the  
> risks if there are any of overridding the id with facebook_id?  Why  
> would I not want to do this?  I did this because, it seems easier to  
> look up a user by their facebook id rather than their id to get  
> their facebook id in associated table.  Meaning if I have an  
> association with a user has_many comments, and the comments has a  
> user_id column.  I think it is easiers looking up things with  
> facebook_ids rather than ids, as these can get confusing.  just one  
> less thing to worry about.
The typical reason for using a surrogate key is to guard against  
changes. In this case, there is a very low probability that Facebook  
will change the id of a user, so that''s not a big deal.

What might be a bigger deal is supporting other platforms. If you  
choose to use the facebook_id as the primary key, what would happen if  
you wanted to add BEBO support?

Mike
>
>
> Does it matter what the order of insertions to the database for  
> creating new Users?
>
> Any insight would be wonderful.
>
> Graciously,
>
> Joe
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
--
Mike Mangino
http://www.elevatedrails.com

2008/11/11 Joseph Durden <josephdurden at
gmail.com>:
> I am new to rails, and was wondering if there would be unknown consequences
> for setting the user tables primary key to being the facebook_id of a user.
> I have implemented this funcionality, and everything is working fine.  All
> associations etc.  What are the risks if there are any of overridding the
id
> with facebook_id?  Why would I not want to do this?
I''m doing this at the moment. The biggest thing I was concerned about
was the potential for facebook user IDs to be 64bit numbers. (I can''t
remember the official Facebook stance on ID size but I''m pretty sure
they weren''t ruling out 64bit IDs). Rails migrations don''t
seem to
support 64bit values (on mysql at least) out-of-the-box.

I worked around the issue by patching ActiveRecord. I added a snippet
(attached) to environment.rb based on the following post and all seems
fine to date:
http://snippets.dzone.com/posts/show/4422

Use column type :int64_pk for your users table and :int64 for any
foreign key columns.

Lee.



-- 
Lee Mallabone.
Director, Crossbone Systems Ltd.

http://www.crossbonesystems.com/
http://www.fonicmonkey.net/
http://CambridgeWebHeads.ning.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mysql-64bit-monkeypatch.rb
Type: text/x-ruby-script
Size: 1097 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/facebooker-talk/attachments/20081111/acb8383e/attachment.bin>

On Nov 11, 2008, at 1:08 PM, Lee Mallabone wrote:
> 2008/11/11 Joseph Durden <josephdurden at gmail.com>:
>> I am new to rails, and was wondering if there would be unknown  
>> consequences
>> for setting the user tables primary key to being the facebook_id of  
>> a user.
>> I have implemented this funcionality, and everything is working  
>> fine.  All
>> associations etc.  What are the risks if there are any of  
>> overridding the id
>> with facebook_id?  Why would I not want to do this?
>
> I''m doing this at the moment. The biggest thing I was concerned
about
> was the potential for facebook user IDs to be 64bit numbers. (I
can''t
> remember the official Facebook stance on ID size but I''m pretty
sure
> they weren''t ruling out 64bit IDs). Rails migrations
don''t seem to
> support 64bit values (on mysql at least) out-of-the-box.
>
> I worked around the issue by patching ActiveRecord. I added a snippet
> (attached) to environment.rb based on the following post and all seems
> fine to date:
> http://snippets.dzone.com/posts/show/4422
>
> Use column type :int64_pk for your users table and :int64 for any
> foreign key columns.
>
For Mysql, just use :integer, :limit=>21

That forces the use of bigints. Facebook is using 64bit user ids.

Mike
> Lee.
>
>
>
> -- 
> Lee Mallabone.
> Director, Crossbone Systems Ltd.
>
> http://www.crossbonesystems.com/
> http://www.fonicmonkey.net/
> http://CambridgeWebHeads.ning.com/
> <mysql-64bit- 
> monkeypatch.rb>_______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
--
Mike Mangino
http://www.elevatedrails.com

As of Rails 2.1 64 bit ints are supported in MySQL migrations.  
Formerly you needed to use a plugin to get this working in MySQL.

Rails 2.1.0 had some problems with the implementation, but in 2.1.1 I  
believe they have fixed the implementation to work the same as  
Postgres, so using :limit => 8 gets you bigint in mysql.

So something like this, should work under Rails 2.1.1 with no patching  
or plugins necessary:
       t.integer :facebook_id, :limit => 8, :null=> false



On Nov 11, 2008, at 10:08 AM, Lee Mallabone wrote:
> 2008/11/11 Joseph Durden <josephdurden at gmail.com>:
>> I am new to rails, and was wondering if there would be unknown  
>> consequences
>> for setting the user tables primary key to being the facebook_id of  
>> a user.
>> I have implemented this funcionality, and everything is working  
>> fine.  All
>> associations etc.  What are the risks if there are any of  
>> overridding the id
>> with facebook_id?  Why would I not want to do this?
>
> I''m doing this at the moment. The biggest thing I was concerned
about
> was the potential for facebook user IDs to be 64bit numbers. (I
can''t
> remember the official Facebook stance on ID size but I''m pretty
sure
> they weren''t ruling out 64bit IDs). Rails migrations
don''t seem to
> support 64bit values (on mysql at least) out-of-the-box.
>
> I worked around the issue by patching ActiveRecord. I added a snippet
> (attached) to environment.rb based on the following post and all seems
> fine to date:
> http://snippets.dzone.com/posts/show/4422
>
> Use column type :int64_pk for your users table and :int64 for any
> foreign key columns.
>
> Lee.
>
>
>
> -- 
> Lee Mallabone.
> Director, Crossbone Systems Ltd.
>
> http://www.crossbonesystems.com/
> http://www.fonicmonkey.net/
> http://CambridgeWebHeads.ning.com/
> <mysql-64bit- 
> monkeypatch.rb>_______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk

You''ll also need to handle the fact that ids in Rails are automatically
incremented so when a user uninstalls the app you won''t be able to
remove
their account (perhaps just mark it as ''disabled'' in your
application or
some similar approach) so when they decide to re-install the app all you
have to do is set it to ''enabled''



-AE

On Tue, Nov 11, 2008 at 10:19 AM, Tres Wong-Godfrey <
tres.wong-godfrey at saniq.com> wrote:
>
> As of Rails 2.1 64 bit ints are supported in MySQL migrations. Formerly you
> needed to use a plugin to get this working in MySQL.
>
> Rails 2.1.0 had some problems with the implementation, but in 2.1.1 I
> believe they have fixed the implementation to work the same as Postgres, so
> using :limit => 8 gets you bigint in mysql.
>
> So something like this, should work under Rails 2.1.1 with no patching or
> plugins necessary:
>      t.integer :facebook_id, :limit => 8, :null=> false
>
>
>
>
> On Nov 11, 2008, at 10:08 AM, Lee Mallabone wrote:
>
>  2008/11/11 Joseph Durden <josephdurden at gmail.com>:
>>
>>> I am new to rails, and was wondering if there would be unknown
>>> consequences
>>> for setting the user tables primary key to being the facebook_id of
a
>>> user.
>>> I have implemented this funcionality, and everything is working
fine.
>>>  All
>>> associations etc.  What are the risks if there are any of
overridding the
>>> id
>>> with facebook_id?  Why would I not want to do this?
>>>
>>
>> I''m doing this at the moment. The biggest thing I was
concerned about
>> was the potential for facebook user IDs to be 64bit numbers. (I
can''t
>> remember the official Facebook stance on ID size but I''m
pretty sure
>> they weren''t ruling out 64bit IDs). Rails migrations
don''t seem to
>> support 64bit values (on mysql at least) out-of-the-box.
>>
>> I worked around the issue by patching ActiveRecord. I added a snippet
>> (attached) to environment.rb based on the following post and all seems
>> fine to date:
>> http://snippets.dzone.com/posts/show/4422
>>
>> Use column type :int64_pk for your users table and :int64 for any
>> foreign key columns.
>>
>> Lee.
>>
>>
>>
>> --
>> Lee Mallabone.
>> Director, Crossbone Systems Ltd.
>>
>> http://www.crossbonesystems.com/
>> http://www.fonicmonkey.net/
>> http://CambridgeWebHeads.ning.com/
>>
>>
<mysql-64bit-monkeypatch.rb>_______________________________________________
>> Facebooker-talk mailing list
>> Facebooker-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>>
>
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/facebooker-talk/attachments/20081111/e0617087/attachment-0001.html>

I use this migration (which makes use of the environment patch I
posted previously) to ensure you don''t get auto-incrementing IDs. They
wouldn''t make much sense when facebook are providing the ID!

      create_table :users, :id => false do |t|
          t.column :id, :int64_pk, :null => false # the facebook uid
          t.column :created_at, :datetime
          t.column :last_seen, :datetime
      end

Lee.


2008/11/11 Anthony C. Eufemio <aeon2012 at
gmail.com>:
> You''ll also need to handle the fact that ids in Rails are
automatically
> incremented so when a user uninstalls the app you won''t be able to
remove
> their account (perhaps just mark it as ''disabled'' in your
application or
> some similar approach) so when they decide to re-install the app all you
> have to do is set it to ''enabled''
>
>
>
> -AE
>
> On Tue, Nov 11, 2008 at 10:19 AM, Tres Wong-Godfrey
> <tres.wong-godfrey at saniq.com> wrote:
>>
>> As of Rails 2.1 64 bit ints are supported in MySQL migrations. Formerly
>> you needed to use a plugin to get this working in MySQL.
>>
>> Rails 2.1.0 had some problems with the implementation, but in 2.1.1 I
>> believe they have fixed the implementation to work the same as
Postgres, so
>> using :limit => 8 gets you bigint in mysql.
>>
>> So something like this, should work under Rails 2.1.1 with no patching
or
>> plugins necessary:
>>      t.integer :facebook_id, :limit => 8, :null=> false
>>
>>
>>
>> On Nov 11, 2008, at 10:08 AM, Lee Mallabone wrote:
>>
>>> 2008/11/11 Joseph Durden <josephdurden at gmail.com>:
>>>>
>>>> I am new to rails, and was wondering if there would be unknown
>>>> consequences
>>>> for setting the user tables primary key to being the
facebook_id of a
>>>> user.
>>>> I have implemented this funcionality, and everything is working
fine.
>>>>  All
>>>> associations etc.  What are the risks if there are any of
overridding
>>>> the id
>>>> with facebook_id?  Why would I not want to do this?
>>>
>>> I''m doing this at the moment. The biggest thing I was
concerned about
>>> was the potential for facebook user IDs to be 64bit numbers. (I
can''t
>>> remember the official Facebook stance on ID size but I''m
pretty sure
>>> they weren''t ruling out 64bit IDs). Rails migrations
don''t seem to
>>> support 64bit values (on mysql at least) out-of-the-box.
>>>
>>> I worked around the issue by patching ActiveRecord. I added a
snippet
>>> (attached) to environment.rb based on the following post and all
seems
>>> fine to date:
>>> http://snippets.dzone.com/posts/show/4422
>>>
>>> Use column type :int64_pk for your users table and :int64 for any
>>> foreign key columns.
>>>
>>> Lee.
>>>
>>>
>>>
>>> --
>>> Lee Mallabone.
>>> Director, Crossbone Systems Ltd.
>>>
>>> http://www.crossbonesystems.com/
>>> http://www.fonicmonkey.net/
>>> http://CambridgeWebHeads.ning.com/
>>>
>>>
<mysql-64bit-monkeypatch.rb>_______________________________________________
>>> Facebooker-talk mailing list
>>> Facebooker-talk at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>>
>> _______________________________________________
>> Facebooker-talk mailing list
>> Facebooker-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>
>
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
>
>


-- 
Lee Mallabone.
Director, Crossbone Systems Ltd.

http://www.crossbonesystems.com/
http://www.fonicmonkey.net/
http://CambridgeWebHeads.ning.com/

On Nov 11, 2008, at 2:50 PM, Lee Mallabone wrote:
> I use this migration (which makes use of the environment patch I
> posted previously) to ensure you don''t get auto-incrementing IDs.
They
> wouldn''t make much sense when facebook are providing the ID!
>
>      create_table :users, :id => false do |t|
>          t.column :id, :int64_pk, :null => false # the facebook uid
>          t.column :created_at, :datetime
>          t.column :last_seen, :datetime
>      end
>

You don''t actually need the id field. If you just use :id=>false on
your migration you can set the primary key field of your model to  
using the primary_key method. For example

class User < ActiveRecord::Base
   primary_key :facebook_id
end

That let''s you use an intention revealing name.

Mike
> Lee.
>
>
> 2008/11/11 Anthony C. Eufemio <aeon2012 at gmail.com>:
>> You''ll also need to handle the fact that ids in Rails are  
>> automatically
>> incremented so when a user uninstalls the app you won''t be
able to
>> remove
>> their account (perhaps just mark it as ''disabled'' in
your
>> application or
>> some similar approach) so when they decide to re-install the app  
>> all you
>> have to do is set it to ''enabled''
>>
>>
>>
>> -AE
>>
>> On Tue, Nov 11, 2008 at 10:19 AM, Tres Wong-Godfrey
>> <tres.wong-godfrey at saniq.com> wrote:
>>>
>>> As of Rails 2.1 64 bit ints are supported in MySQL migrations.  
>>> Formerly
>>> you needed to use a plugin to get this working in MySQL.
>>>
>>> Rails 2.1.0 had some problems with the implementation, but in  
>>> 2.1.1 I
>>> believe they have fixed the implementation to work the same as  
>>> Postgres, so
>>> using :limit => 8 gets you bigint in mysql.
>>>
>>> So something like this, should work under Rails 2.1.1 with no  
>>> patching or
>>> plugins necessary:
>>>     t.integer :facebook_id, :limit => 8, :null=> false
>>>
>>>
>>>
>>> On Nov 11, 2008, at 10:08 AM, Lee Mallabone wrote:
>>>
>>>> 2008/11/11 Joseph Durden <josephdurden at gmail.com>:
>>>>>
>>>>> I am new to rails, and was wondering if there would be
unknown
>>>>> consequences
>>>>> for setting the user tables primary key to being the
facebook_id
>>>>> of a
>>>>> user.
>>>>> I have implemented this funcionality, and everything is
working
>>>>> fine.
>>>>> All
>>>>> associations etc.  What are the risks if there are any of  
>>>>> overridding
>>>>> the id
>>>>> with facebook_id?  Why would I not want to do this?
>>>>
>>>> I''m doing this at the moment. The biggest thing I was
concerned
>>>> about
>>>> was the potential for facebook user IDs to be 64bit numbers. (I
>>>> can''t
>>>> remember the official Facebook stance on ID size but
I''m pretty
>>>> sure
>>>> they weren''t ruling out 64bit IDs). Rails migrations
don''t seem to
>>>> support 64bit values (on mysql at least) out-of-the-box.
>>>>
>>>> I worked around the issue by patching ActiveRecord. I added a  
>>>> snippet
>>>> (attached) to environment.rb based on the following post and
all
>>>> seems
>>>> fine to date:
>>>> http://snippets.dzone.com/posts/show/4422
>>>>
>>>> Use column type :int64_pk for your users table and :int64 for
any
>>>> foreign key columns.
>>>>
>>>> Lee.
>>>>
>>>>
>>>>
>>>> --
>>>> Lee Mallabone.
>>>> Director, Crossbone Systems Ltd.
>>>>
>>>> http://www.crossbonesystems.com/
>>>> http://www.fonicmonkey.net/
>>>> http://CambridgeWebHeads.ning.com/
>>>>
>>>> <mysql-64bit- 
>>>>
monkeypatch.rb>_______________________________________________
>>>> Facebooker-talk mailing list
>>>> Facebooker-talk at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>>>
>>> _______________________________________________
>>> Facebooker-talk mailing list
>>> Facebooker-talk at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>>
>>
>> _______________________________________________
>> Facebooker-talk mailing list
>> Facebooker-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>>
>>
>
>
>
> -- 
> Lee Mallabone.
> Director, Crossbone Systems Ltd.
>
> http://www.crossbonesystems.com/
> http://www.fonicmonkey.net/
> http://CambridgeWebHeads.ning.com/
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
--
Mike Mangino
http://www.elevatedrails.com

Mike, you said specifying :limit =>21 should allow support for 64 bit
integers?  this did not work in rails 2.1.2, as i had to do the following to
get a mysql bigint(20) to work in my users table:

t.column :facebook_id, ''bigint'', :null => false

Upon running a migration, I get a successful bigint(20) column in my mysql
database.  with :limit =>21, i was getting an integer column in mysql.

I was required to have a bigint column when using facebooker_authentication
and integrating with Bebo.  I was receiving duplicate key errors within
facebooker_authentication model.rb file in the following method:

      def for_facebook_id(facebook_id,facebook_session=nil)
            returning find_or_create_by_facebook_id(facebook_id) do |user|
                unless facebook_session.nil?
                    user.store_session(facebook_session.session_key)
                end
            end
        end

I was getting a Mysql::Error: duplicate key entry on returning
find_or_create_by_facebook_id(facebook_id) when integrating with Bebo.
After changing the column in mysql to bigint, everything is now working as
expected.

Would you recommend against setting ''bigint'' directly in the
migration file,
and if so, what would you suggest, and is bigint(20) enough, or should it be
bigint(64)?

Joe

On Tue, Nov 11, 2008 at 10:16 AM, Mike Mangino
<mmangino at elevatedrails.com>wrote:
>
> On Nov 11, 2008, at 1:08 PM, Lee Mallabone wrote:
>
>  2008/11/11 Joseph Durden <josephdurden at gmail.com>:
>>
>>> I am new to rails, and was wondering if there would be unknown
>>> consequences
>>> for setting the user tables primary key to being the facebook_id of
a
>>> user.
>>> I have implemented this funcionality, and everything is working
fine.
>>>  All
>>> associations etc.  What are the risks if there are any of
overridding the
>>> id
>>> with facebook_id?  Why would I not want to do this?
>>>
>>
>> I''m doing this at the moment. The biggest thing I was
concerned about
>> was the potential for facebook user IDs to be 64bit numbers. (I
can''t
>> remember the official Facebook stance on ID size but I''m
pretty sure
>> they weren''t ruling out 64bit IDs). Rails migrations
don''t seem to
>> support 64bit values (on mysql at least) out-of-the-box.
>>
>> I worked around the issue by patching ActiveRecord. I added a snippet
>> (attached) to environment.rb based on the following post and all seems
>> fine to date:
>> http://snippets.dzone.com/posts/show/4422
>>
>> Use column type :int64_pk for your users table and :int64 for any
>> foreign key columns.
>>
>>
> For Mysql, just use :integer, :limit=>21
>
> That forces the use of bigints. Facebook is using 64bit user ids.
>
> Mike
>
>  Lee.
>>
>>
>>
>> --
>> Lee Mallabone.
>> Director, Crossbone Systems Ltd.
>>
>> http://www.crossbonesystems.com/
>> http://www.fonicmonkey.net/
>> http://CambridgeWebHeads.ning.com/
>>
>>
<mysql-64bit-monkeypatch.rb>_______________________________________________
>> Facebooker-talk mailing list
>> Facebooker-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>>
>
> --
> Mike Mangino
> http://www.elevatedrails.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/facebooker-talk/attachments/20081111/10b137e0/attachment-0001.html>