A quick question on biblioitems.dewey field's datatype
Hi, Why is the biblioitems.dewey field set to double(8,6) and not to, say varchar(15) or something like that? After all in the MARC subfield table the dewey gets stored in a varchar(255) field. Any pointers/clues on this? tia -indra -- ------------------------------------------------------------- Indranil Das Gupta, Project Lead, CASTLE Project [Computer Aided Studies, Teaching and Learning Environment] In collaboration with: West Bengal University of Technology Calcutta, INDIA www.wbut.net ------------------------------------------------------------- L2C2.ORG - Bringing Localized Low-Cost Computing to People -------------------------------------------------------------
On 2004-08-22 12:06:33 +0100 Indranil Das Gupta <indradg@icbic.com> wrote:
Why is the biblioitems.dewey field set to double(8,6) and not to, say varchar(15) or something like that?
I think quite a few developers have been wondering that recently, too. Unless there's a killer reason to keep it numeric, I expect it to change in 2.1.* before much longer. -- MJR/slef My Opinion Only and not of any group I know
On Sun, 2004-08-22 at 22:49, MJ Ray wrote:
On 2004-08-22 12:06:33 +0100 Indranil Das Gupta <indradg@icbic.com> wrote:
Why is the biblioitems.dewey field set to double(8,6) and not to, say varchar(15) or something like that?
I think quite a few developers have been wondering that recently, too. Unless there's a killer reason to keep it numeric, I expect it to change in 2.1.* before much longer.
Thanks for the info. At my deployment site, use of double precision datatype was leading to the decimal part of the stored dewey number being padded with extra zeros. And this was reflecting a wrong value in the OPAC interface. So, I simply changed the fieldtype to varchar(15) and rerun misc/rebuildnonmarc.pl. Now, the dewey value is being correctly stored in biblioitems.dewey and properly displayed in the OPAC. So far, I haven't noticed any inconsistency due to the change. cheers, -indra. -- ------------------------------------------------------------- Indranil Das Gupta, Project Lead, CASTLE Project [Computer Aided Studies, Teaching and Learning Environment] In collaboration with: West Bengal University of Technology Calcutta, INDIA www.wbut.net ------------------------------------------------------------- L2C2.ORG - Bringing Localized Low-Cost Computing to People -------------------------------------------------------------
Indranil Das Gupta wrote:
On Sun, 2004-08-22 at 22:49, MJ Ray wrote:
On 2004-08-22 12:06:33 +0100 Indranil Das Gupta <indradg@icbic.com> wrote:
Why is the biblioitems.dewey field set to double(8,6) and not to, say varchar(15) or something like that?
I think quite a few developers have been wondering that recently, too. Unless there's a killer reason to keep it numeric, I expect it to change in 2.1.* before much longer.
Thanks for the info. At my deployment site, use of double precision datatype was leading to the decimal part of the stored dewey number being padded with extra zeros. And this was reflecting a wrong value in the OPAC interface.
So, I simply changed the fieldtype to varchar(15) and rerun misc/rebuildnonmarc.pl. Now, the dewey value is being correctly stored in biblioitems.dewey and properly displayed in the OPAC.
So far, I haven't noticed any inconsistency due to the change.
cheers, -indra.
Not knowing the language very well, and not knowing the dewey decimal system very well, I can nonetheless venture a guess based upon my experience in other computer areas. If the number of characters after the decimal point ever changes, then it will not sort properly. If the field is changed to varchar, I would make sure to put in some sort of edit mask / edit check to verfy the number of characters after the decimal point. If there are less than some minimal number, space fill to the right. Bob
participants (3)
-
Bob Seidl -
Indranil Das Gupta -
MJ Ray