How we can input a very large field
We are making some fixes into our production instalation. We noticed that the input field in cataloging only allows 255 characters and is an input field. We have currently resume fields that are much larger than that (about 3000 characters). We re trying to develop a way to make our templates aware of the fact that a field is large enough to be better input in a text field insted of an input field. We want to develop something more generic. An idea we have: having in the system preferences a list of fields that may contain large values. When we're about displaying an input field we should take into account the systems preferences. We will accept your fedback, we hope we can contribute this back to the CVS. Andres
Greetings! While this would represent a lot of work, I'm sure, the solution would be to have a cataloguing mode that allowed input of data directly into a MARC record structure. The record structure allows for single (sub)field size of 9999 characters, which should be more than enough to meet your needs. Maximum record size is 99999 characters, but that is ample. The average MARC record runs under 3000 characters. Something to think about, surely. Al Calame Librarian-at-Large Montreal, Canada Andrés Tarallo wrote:
We are making some fixes into our production instalation. We noticed that the input field in cataloging only allows 255 characters and is an input field. We have currently resume fields that are much larger than that (about 3000 characters).
We re trying to develop a way to make our templates aware of the fact that a field is large enough to be better input in a text field insted of an input field. We want to develop something more generic.
An idea we have: having in the system preferences a list of fields that may contain large values. When we're about displaying an input field we should take into account the systems preferences.
We will accept your fedback, we hope we can contribute this back to the CVS.
Andres
------------------------------------------------------- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
Albert: The solution you are proposig seem to be very clean. For doing that some fieldos should be blobs. However in the current DB Schema is not clear to me that this can be done. On the other hand searches in blobs could be very slow. Andres Albert P. Calame wrote:
Greetings! While this would represent a lot of work, I'm sure, the solution would be to have a cataloguing mode that allowed input of data directly into a MARC record structure. The record structure allows for single (sub)field size of 9999 characters, which should be more than enough to meet your needs. Maximum record size is 99999 characters, but that is ample. The average MARC record runs under 3000 characters. Something to think about, surely.
Al Calame Librarian-at-Large Montreal, Canada
Andrés Tarallo wrote:
We are making some fixes into our production instalation. We noticed that the input field in cataloging only allows 255 characters and is an input field. We have currently resume fields that are much larger than that (about 3000 characters).
We re trying to develop a way to make our templates aware of the fact that a field is large enough to be better input in a text field insted of an input field. We want to develop something more generic.
An idea we have: having in the system preferences a list of fields that may contain large values. When we're about displaying an input field we should take into account the systems preferences.
We will accept your fedback, we hope we can contribute this back to the CVS.
Andres
Andrés Tarallo a écrit :
Albert:
The solution you are proposig seem to be very clean. For doing that some fieldos should be blobs. However in the current DB Schema is not clear to me that this can be done. On the other hand searches in blobs could be very slow. Andres
The DB scheme & Koha perl code supports fields > 255 char. The problem was only in HTML that had a limit to 255. In marc_words, there is a bloblink field. It's field only if the entry is >255 char. In this case, the bloblink contains the number of the blob in marc_blob file. With this, you have fields <255 easily accessible & other still managed. Note that with marc_word structure all words are indexed, so SearchMarc.pm can deal with any size with indexed performances. Hope it's clear. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 5/26/05, Paul POULAIN <paul.poulain@free.fr> wrote:
Andrés Tarallo a écrit :
Albert:
The solution you are proposig seem to be very clean. For doing that some fieldos should be blobs. However in the current DB Schema is not clear to me that this can be done. On the other hand searches in blobs could be very slow. Andres
The DB scheme & Koha perl code supports fields > 255 char. The problem was only in HTML that had a limit to 255. In marc_words, there is a bloblink field. It's field only if the entry is >255 char. In this case, the bloblink contains the number of the blob in marc_blob file. With this, you have fields <255 easily accessible & other still managed. Note that with marc_word structure all words are indexed, so SearchMarc.pm can deal with any size with indexed performances.
Hope it's clear.
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
As a side note, from my work in Wikipedia, who also use MySQL, that storing large blobs of text in the database itself is a very bad thing, due to major performance hits once you start getting large numbers of them. Corey
Andrés Tarallo a écrit :
We are making some fixes into our production instalation. We noticed that the input field in cataloging only allows 255 characters and is an input field. We have currently resume fields that are much larger than that (about 3000 characters).
We re trying to develop a way to make our templates aware of the fact that a field is large enough to be better input in a text field insted of an input field. We want to develop something more generic.
An idea we have: having in the system preferences a list of fields that may contain large values. When we're about displaying an input field we should take into account the systems preferences.
We will accept your fedback, we hope we can contribute this back to the CVS. In the last version (2.2.2b) the limit of 255 chars has been removed. PLUS : when a field is more than 200 chars, the next time the biblio is edited, it's shown as a textarea. automatically.
I agree it's not a perfect solution for the 1st edition. I can do something else, but it's a dirty hack imho : if there is [textarea] in subfield name (like "010$a : ISBN [textarea]"), then I could remove [textarea] and use a textarea input even on an empty record. The best solution being, imho, to add another constraint in marc_subfield_structure, that would be the size (length & height) of the field. If height=1, then it's an input. if >1, then it's a textarea. The length being usefule whatever height is (it's stupid to have isbn=255 char. 10 (13 soon) would be enough) This requires some (minor) changes in the DB, so i won't do it in 2.2 branch. But if it sounds interesting, I could add this to 2.4 features. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
We have worked out the solution described in my previous mail. It's not the best, and it's not tested in deep. I like your proposal. I will study it with Ernesto Silva here in ORT and see if we can implement it. Andres Paul POULAIN wrote:
Andrés Tarallo a écrit :
We are making some fixes into our production instalation. We noticed that the input field in cataloging only allows 255 characters and is an input field. We have currently resume fields that are much larger than that (about 3000 characters).
We re trying to develop a way to make our templates aware of the fact that a field is large enough to be better input in a text field insted of an input field. We want to develop something more generic.
An idea we have: having in the system preferences a list of fields that may contain large values. When we're about displaying an input field we should take into account the systems preferences.
We will accept your fedback, we hope we can contribute this back to the CVS.
In the last version (2.2.2b) the limit of 255 chars has been removed. PLUS : when a field is more than 200 chars, the next time the biblio is edited, it's shown as a textarea. automatically.
I agree it's not a perfect solution for the 1st edition.
I can do something else, but it's a dirty hack imho : if there is [textarea] in subfield name (like "010$a : ISBN [textarea]"), then I could remove [textarea] and use a textarea input even on an empty record.
The best solution being, imho, to add another constraint in marc_subfield_structure, that would be the size (length & height) of the field. If height=1, then it's an input. if >1, then it's a textarea. The length being usefule whatever height is (it's stupid to have isbn=255 char. 10 (13 soon) would be enough)
This requires some (minor) changes in the DB, so i won't do it in 2.2 branch. But if it sounds interesting, I could add this to 2.4 features.
participants (4)
-
Albert P. Calame -
Andrés Tarallo -
Corey Burger -
Paul POULAIN