Sequel primary keys

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

I posted to the Sequel Google Group but it's horribly slow, assuming it took
my post.

Does anyone on here know if it is possible to create a non-integer primary
key in Sequel? If so how? Also help with creating a non integer foreign
key would be great too. I've done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or AUTOINCREMENT.

Thanks,
Glen

 

[Robert Klemme]

I posted to the Sequel Google Group but it's horribly slow, assuming it took
my post.

Does anyone on here know if it is possible to create a non-integer primary
key in Sequel? If so how? Also help with creating a non integer foreign
key would be great too. I've done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or AUTOINCREMENT.

The docs seem to indicate that you can use arbitrary PK's:

http://sequel.rubyforge.org/classes/Sequel/Schema/Generator.html#M000257

So, if int is enforced there is a bug - either in your code or in
Sequel's code.

Kind regards

robert

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

The docs seem to indicate that you can use arbitrary PK's:

http://sequel.rubyforge.org/classes/Sequel/Schema/Generator.html#M000257

So, if int is enforced there is a bug - either in your code or in Sequel's
code.

Kind regards

robert

Thanks for the input Robert.

It turns out there is a rather vaguely documented :auto_increment => false
that needed to be included in my primary_key definition. Now I just need to
figure out how to get foreign_keys to work. The sequel-talk group seems to
be working so I will continue this pursuit there.

Thanks again.

 

[Todd Benson]

Thanks for the input Robert.

It turns out there is a rather vaguely documented :auto_increment => false
that needed to be included in my primary_key definition. Now I just need to
figure out how to get foreign_keys to work. The sequel-talk group seems to
be working so I will continue this pursuit there.

Thanks again.

--
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can't hear a word you're saying."

-Greg Graffin (Bad Religion)

I don't want to hijack this thread, and people may be mad about me
saying this again. Will you (that would be people in general and
doesn't include Greg as far as I can see) please stop using
auto_increment as a guarantee of uniqueness in a database/set?! The
set theory should be handled in the db anyway, IMHO.

It's convenient, but think, for example, if you move a postresql db
schema to oracle, or vice versa, or even worse to SQLite (nothing
against you guys, I think you have a really cool product and am
looking forward to future updates). Anyways, "Uh-oh." "Price is
Right" ... buy another key so we can move on. Silly. This is how
mud/clay is added to structures because people think they are being
practical engineers.

Ruby is good stuff. Let's use it in a good way! Likewise, the
databases need to be used correctly.

Todd

 

[Robert Klemme]

[Note: parts of this message were removed to make it a legal post.]

The docs seem to indicate that you can use arbitrary PK's:

http://sequel.rubyforge.org/classes/Sequel/Schema/Generator.html#M000257

So, if int is enforced there is a bug - either in your code or in Sequel's
code.

Thanks for the input Robert.

You're welcome.

It turns out there is a rather vaguely documented :auto_increment => false
that needed to be included in my primary_key definition. Now I just need to
figure out how to get foreign_keys to work.

I have seen this documented in the docs. Does it not work as advertised?

The sequel-talk group seems to
be working so I will continue this pursuit there.

Good chances that you get more profound feedback there.

Cheers

robert

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

[Note: parts of this message were removed to make it a legal post.]

On Tue, Jun 24, 2008 at 11:03 AM, Robert Klemme <
(e-mail address removed)>
wrote:

I posted to the Sequel Google Group but it's horribly slow, assuming it
took
my post.

Does anyone on here know if it is possible to create a non-integer
primary
key in Sequel? If so how? Also help with creating a non integer
foreign
key would be great too. I've done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or
AUTOINCREMENT.

The docs seem to indicate that you can use arbitrary PK's:

http://sequel.rubyforge.org/classes/Sequel/Schema/Generator.html#M000257

So, if int is enforced there is a bug - either in your code or in
Sequel's
code.

Thanks for the input Robert.

You're welcome.

It turns out there is a rather vaguely documented :auto_increment => false

that needed to be included in my primary_key definition. Now I just need
to
figure out how to get foreign_keys to work.

I have seen this documented in the docs. Does it not work as advertised?

I didn't run across it in my initial search. The pirmary_key method
doc says to see column for available options. There is no :auto_increment
listed in the valid options for column. It is logical that it would exist
but I didn't see it in the doc. At least it didn't appear in a straight
forward manner.

The sequel-talk group seems to

Good chances that you get more profound feedback there.

Turns out Jeremy was having to approve my messages to the Google Group/list
which explains why it appeared to be acting oddly.

 

[Dave Bass]

Does anyone on here know if it is possible to create a non-integer
primary
key in Sequel?

If you mean a floating-point primary key, that doesn't sound like a good
idea, for the same reason that doing == comparisons with floats isn't a
good idea.

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

If you mean a floating-point primary key, that doesn't sound like a good
idea, for the same reason that doing == comparisons with floats isn't a
good idea.

No, I was looking to do more what Todd was talking about. I've never seen
any reason to generate a pointless counter for a key and in analog extra
constraints when the DBMS handles it for you simply by working in sets (and
in some cases bags). If my DB is a model of real world entities as it
should be then there should be a unique indentifier for said entities which
means I shouldn't have to number them just because.

In other words I am using necessary table elements as keys.

 

[Rimantas Liubertas]

If my DB is a model of real world entities as it
should be then there should be a unique indentifier for said entities which
means I shouldn't have to number them just because.

In other words I am using necessary table elements as keys.

The problem with "real world" unique identifiers is that even if they
stay uniqui they
_may_ change. The worst part it that they do change, even those you though would
never ever possible change.
Surrogate keys do not have this problem. They may have other problems,
but it is worth it,
imho.

Regards,
Rimantas

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

The problem with "real world" unique identifiers is that even if they
stay uniqui they
_may_ change. The worst part it that they do change, even those you though
would
never ever possible change.
Surrogate keys do not have this problem. They may have other problems,
but it is worth it,
imho.

Regards,
Rimantas

I'm curious as to when and why it matters if a primary key is mutable or
not. As long as it is still unique and any necessary side-effects are
handled either by the app or the DBMS.

 

[Rimantas Liubertas]

I'm curious as to when and why it matters if a primary key is mutable or

not. As long as it is still unique and any necessary side-effects are
handled either by the app or the DBMS.

Well, the first time you have to handle those side effects in your
app you will see why it matters


Regards,
Rimantas

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

Well, the first time you have to handle those side effects in your
app you will see why it matters


Regards,
Rimantas

I've always believed it was more the role of the DBMS to handle such things
anyway. Especially when you have data being accessed by multiple
applications.

 

[Todd Benson]

The problem with "real world" unique identifiers is that even if they
stay uniqui they
_may_ change

You mean schema change, or something else?

The worst part it that they do change, even those you though would
never ever possible change.

Please clarify.

Surrogate keys do not have this problem. They may have other problems,
but it is worth it,
imho.

Regards,
Rimantas

That sounds more like a schema design problem than a programming one.
Of course, this debate will go on forever in db circles. Some swear
upon OO and other styles of dbs, even. I sort of side with Celko
(smart guy with a somewhat bearable cocky attitude that writes db
books and used to frequent -- maybe still does --
comp.databases.theory) and personally like the RDBMS. Even though
Ruby is very OO, it does lend itself well to set theory. But, to each
his or her own.

There's nothing wrong with surrogate keys, really. But the whole
arbitrary number defining a tuple's existence and uniqueness doesn't
move well across platforms. Not only that, having to define extra
UNIQUE constraints to make logical sense is redundant.. This is one
of the reasons I tend to avoid using Rails simply because it's not
simple to do what I want.

Taking care of such a thing in the app will not scale well. For
situations where you prefer convenience instead of data integrity or
all the unit tests you want to write to ensure that integrity, then I
guess it's applicable.

Todd

P.S.
Sorry for calling Glen Greg.

 

[Todd Benson]

I posted to the Sequel Google Group but it's horribly slow, assuming it took
my post.

Does anyone on here know if it is possible to create a non-integer primary
key in Sequel? If so how? Also help with creating a non integer foreign
key would be great too. I've done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or AUTOINCREMENT.

Thanks,
Glen

Hey Glen, can you give us an answer about whether primary key and
foreign key can be handled by the designer for certain databases with
Sequel? I'll RTFM eventually, but was just curious if you found out.

thanks,
Todd

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

Hey Glen, can you give us an answer about whether primary key and
foreign key can be handled by the designer for certain databases with
Sequel? I'll RTFM eventually, but was just curious if you found out.

thanks,
Todd

Yeah, you can. For example:

class Computer < Sequel::Model
set_schema do
primary_key :name, :type => :text, :auto_increment => false
varchar s
varchar :ip
varchar :mac
foreign_key :lab, :labs, :type => :text
end

many_to_one :lab
end # Computer class

 

[Todd Benson]

Yeah, you can. For example:

class Computer < Sequel::Model
set_schema do
primary_key :name, :type => :text, :auto_increment => false
varchar s
varchar :ip
varchar :mac
foreign_key :lab, :labs, :type => :text
end

many_to_one :lab
end # Computer class

Thanks a lot. I think I'll really look into using the sequel gem!
I'm so familiar with SQL92 that it's hard to move on

Todd