Just noticed, bdb’s Hash interface doesn’t pay attention to $=.
Is this a bug? Or should I accept this and write an intermediate class
to wrap [], has_key? etc.
Tom.
···
–
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | tom@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------’
Now, I can wrap the Hash, but I have to point out that the lack of $=
sucks. My has_key? implementation will have to iterate over every key in
the Hash, and compare using tolower. This is slow as poop, plus a lot of
these kind of modules (don’t know about bdb explicitly) may have access
to some nice efficient way of doing case insensitive comparisons (a flag
to toggle use of strcasecmp() or whatever), and without $= I can’t
access it
What’s the point of a Hash interface when I have to iterate over every
key for each lookup?
Hrm. I have a feeling the only way I could use this would be to tolower!
every key, right? But wouldn’t that mean that the case information was
lost in the db itself?
e.g, I want to store a key “Fred Jones”, but be able to lookup “fred
jones”, and still have it display as “Fred Jones”, if you see what I
mean…
Now, I can wrap the Hash, but I have to point out that the lack of $=
sucks. My has_key? implementation will have to iterate over every key in
the Hash, and compare using tolower. This is slow as poop, plus a lot of
AFAIK, BDB is case-sensitive. This means, lower-case handling has to
be done by yourself by either the method you described above or by
normalising (lower-casing) the keys on storing. The original key can
be stored as another field on the record so upon retrieval, the
original key can be extracted. You may compress the original key first
to save some space.
Hrm. I have a feeling the only way I could use this would be to tolower!
every key, right? But wouldn't that mean that the case information was
lost in the db itself?
yes,
e.g, I want to store a key "Fred Jones", but be able to lookup "fred
jones", and still have it display as "Fred Jones", if you see what I
mean..
Try this :
pigeon% cat b.rb
#!/usr/bin/ruby
require 'bdb'
module BDB
class A < Btree
def bdb_bt_compare(a, b)
a.downcase <=> b.downcase
end
end
end
db = BDB::A.open "basic", nil, "w"
db["Fred Jones"] = "abc"
p db["fred jones"]
p db.keys
pigeon%
More accurately, perhaps, is: keys in BDB are just strings of bytes.
If you want to look at them as text, that’s fine, but there’s no
particular reason that BDB itself should.
If you want case insensitivity, you’ll have to provide it.
It is much more useful to have arbitrary strings of bytes (up to 2Gb
long!) as keys than it is to have merely text…
···
On Tuesday 23 July 2002 12:35 pm, Yohanes Santoso wrote:
Okay, that looks nice. However I’m currently using BDB::Hash because I
don’t really need sorted access to the keys. I can switch to BDB::Btree,
if there aren’t any major penalties for doing so… I know I’ll lose all
my existing data saved in db’s opened using the Hash api though I
assume there’s no way to set the compare function for BDB::Hash?
Hrm. I have a feeling the only way I could use this would be to tolower!
every key, right? But wouldn’t that mean that the case information was
lost in the db itself?
yes,
e.g, I want to store a key “Fred Jones”, but be able to lookup “fred
jones”, and still have it display as “Fred Jones”, if you see what I
mean…
Try this :
pigeon% cat b.rb
#!/usr/bin/ruby
require ‘bdb’
module BDB
class A < Btree
def bdb_bt_compare(a, b)
a.downcase <=> b.downcase
end
end
end
db = BDB::A.open “basic”, nil, “w”
db[“Fred Jones”] = “abc”
p db[“fred jones”]
p db.keys
pigeon%
pigeon% b.rb
“abc”
[“Fred Jones”]
pigeon%
–
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | tom@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------’
On Tuesday 23 July 2002 12:35 pm, Yohanes Santoso wrote:
AFAIK, BDB is case-sensitive.
More accurately, perhaps, is: keys in BDB are just strings of bytes.
If you want to look at them as text, that’s fine, but there’s no
particular reason that BDB itself should.
If you want case insensitivity, you’ll have to provide it.
It is much more useful to have arbitrary strings of bytes (up to 2Gb
long!) as keys than it is to have merely text…
–
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | tom@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------’
Okay, that looks nice. However I'm currently using BDB::Hash because I
don't really need sorted access to the keys. I can switch to BDB::Btree,
if there aren't any major penalties for doing so.. I know I'll lose all
my existing data saved in db's opened using the Hash api though I
assume there's no way to set the compare function for BDB::Hash?
Okay, that looks nice. However I’m currently using BDB::Hash because I
don’t really need sorted access to the keys. I can switch to BDB::Btree,
if there aren’t any major penalties for doing so… I know I’ll lose all
my existing data saved in db’s opened using the Hash api though I
assume there’s no way to set the compare function for BDB::Hash?