I have a list of books in an Excel file and I would like to import it into Biblioteq.
Is there a proper way to do this, so that I wouldn't have to add each one, manually?
I have tried to do something but, although I can see the books in the app and can access them, I have lost the search functionality: when searching for a book or if I click on the links created automatically by the app for the categories or the authors, I don't get the correct results (I get fewer results)
Thank you for your answer.
The only supported mechanism for creating entries is the BiblioteQ interface. BiblioteQ supports two sophisticated database schemas with all sorts of attributes. If you inserted the items using another mechanism, I'm not surprised that the end results are corrupt.
Did you add any items with BiblioteQ?
Thank you for your answer.
The items added with BiblioteQ's interface work fine, but that's going to take a lot of time to load all the books into the app.
Do you have any ideas on how I could accelerate the process?
Are you considering implementing an Import function that could solve the problem more easily?
You can study the applicable schema and create a script to import the data.
The solution that you're aiming for isn't pleasant. Importing user data requires thinking. I'll review some bothersome thoughts. What's the format of the data? Where is the title column? Where is the ISBN? Speaking as a program. What do I do if I can't find a required field? How many irresolvable errors do I produce before the user becomes aggravated? Other thoughts. Perhaps the user should be able to define the data and BiblioteQ will use some definition to ingest the data. Should these definitions be provided as plain files or via some fancy interface? What if the definitions are incorrect? Should BiblioteQ have validators of import definitions? How is the data separated? Can the separation provide sufficient support for international symbols? How many import file types should BiblioteQ support? How about uniqueness errors? Those are some of the reasons that cause me to abandon import support.
I'm in the same situation-over 3000 books to enter.
Could there be some kind of batch input based on at least ISBN numbers? If it would simply pull in the number, do its normal lookup, let me view it and press the save button and go on to the next. That alone would save hours of work. I trust the Z39.50 data more than what employees and voluteers have entered over the years. :)
Then, if that were working, it shouldn't be too hard to do something similar for LCCN or titles for the older books without ISBN's.
An interesting proposal. I've been asked several times for an import feature. I've stayed away from such requests because the resolutions tend to be customized. A universal resolution would take considerable time. I understand that it's a burden to enter a lot of data. However, BQ has a very, very small part-time staff (< 2).
Z39.50 queries require ISBNs. Other fields are not supported. I don't remember if users have asked for support of other fields. You're encouraged to make a formal request.
I'm working on version 6.59. The goal of that version is photographs and SRU support.
I'm also working on non-BQ projects that have their own priorities.
Thank you for showing an interest.
Ok. Looks like my best option is to roll my own. Do you have time to give some advice or do I need to try to figure things out from the code? The main questions I have are:
1. Are book and book_copy_info the only tables I need to update?
2. I think other than "myoid" the book fields are self-explanatory. How would i assign a value there?
3. Can you give a brief description of the fields in book_copy_info?
4. For books without an ISBN, can I use a sequential number padded to the left with 0's?
I think I can answer #1 and #2. It looks like myoid comes from sequence and becomes item_oid for book_copy_info which gets the next sequence number for its myoid. Thus, I also need to update sequence. I didn't see any more INSERTs in the db dump.
Fortunately, ISBNs are not required. (Notice the checkbox?) If you need random ISBNs, yes. The ISBNs need to be unique as there are certain database constraints. The myoid field is similar to a sequence. It must be unique for a table. Are you using Postgres or SQLite? For Postgres, the database assumes all responsibility. For SQLite, you'll need to formulate unique integers (BQ does it for free).
A library can have multiple copies of one item. That's the intent of the copy tables. The item_oid is the book's internal unique id (book's myoid), the myoid is the copy's internal unique id, the copyid is some value that the user would provide (the interface provides simple defaults), and the copy number is the copy number (copy 1, copy 2, etc.).
Yah, myoid is a super-secret number used by BQ. The myoid field also provides clean relationships between tables. I don't think SQLite supports sequences in the way that PostgreSQL does. I love Postgres! I tried to remove as much data integrity from the application as possible. Postgres is quite powerful. Use it whenever you can.
Log in to post a comment.