Discussion: Custom Fields

Grunthos

There have been a few requests for new fields:

• Date loaned
• Date to return
• Language
• Date purchased
• Maxi series (edit 31/1/2011) I think we should just allow multiple series per book as per LibraryThing
• No of copies

Some of these really foreshadowed improved features eg. Loan and return stuff could be enhanced and # of copies presupposes a solution to duplicate management.

But I wonder if there is any value in considering allowing the user to add fields at runtime. They would need to be limited to certain types etc...but is it worth pursuing as an idea?

eleybourn

I definitely think it is a good idea. However it is a major change. It has implications on the database as well as the interface. We would need to consider data types, entry methods, placements on screen and tabs, visibility controls, etc. Your thoughts?

Grunthos

We may need a forum or something for design discussions, but in the mean time, I'd suggest something along the lines of:

1. . Define some limited data types we can support in the first version: integer, real, date, isbn and string, possibly with some basic validation on some of them (like a range for numbers). Maybe even just start with strings. Store these in a table called attribute_types (say). Handling of these types will be hard-coded somewhere.
2. . Allow the user to create a new field for books. They provide:
   • display name (eg. 'Date Eaten').
   • unique id (string name that is less pretty) eg. 'date_eaten'
   • the basic type (ed. 'Date' as above).
   • limits (length for string, min/max for numbers)
   • sort position
   • (Store these in a table called book_attribute_definitions (say)).
3. Alter the 'Comments' tab (or edit tab) to include the custom fields at the end. These will be appended accoring to the provided sort position followed by the name.
4. Store the values in a table called book_attribute_values (say) when a book is edited.
5. Consider adding an 'attribute_group' field on attributes. Then, when displaying attributes always put the same group on one line. This would handle fields like 'series' and 'series #' which look best on one line.
6. (Maybe, perhaps in later version) Build a search/sort tool that allows queries to be constructed based on these attributes.
7. Consider which, if any, existing attributes should become custom attributes.
8. Consider, adding all existing attributes as 'intrinsic' types so that the search tool in 6 might be useable...
9. Bear in mind that sorting and searching on these attributes will be slower. We may in fact want to build a real table using the unique attribute IDs then issue the relevant 'ALTER TABLE' commands when a new attribute is defined. In this case, I would start with a table book_attributes(id foregn key ref book) and just append/delete columns as necessary. We would still need book_attribute_definitions to define the type and rules for each attribute.