MobileRead Forums - View Single Post - Documentation: How to Add a New Custom Column Datatype

chaley · 07-03-2016, 05:24 AM

When considering what is the "hard part", also bear in mind that adding a datatype is likely to break any third-party tools that directly read the calibre database or calibre .opf information. One example class of such tools are the alternate content servers. In addition, this kind of change is arguably like a schema change and not backwards compatible, preventing people from downgrading if required or from running both calibre V(current) and V(old) because their hardware requires it.

For this new datatype, plaintext, a much less risky approach would be to add 1 or 2 new booleans to the "display" for comments: "is_plain_text" and (possibly) "show_label". Column writers (and there aren't many of those) would need to be sure that they don't "html"ify the contents and present an appropriate editor to the user. Column readers might need to check, but given that it is currently possible that a comments column contain plain text, it isn't clear how often such a check is required. SW that copies column data (e.g., OPF stuff) probably need no changes at all.

This approach has several large advantages:

There aren't two column types that are largely the same thing. This is one reason I probably should have implemented the enumerated type using the display instead of as a distinct datatype.
Clients who read the database won't break. In rare cases they might show the data incorrectly (e.g., embedded text that looks like HTML), but that is more acceptable than falling over dead.
Clients that care about the semantics of the new booleans can adapt their behavior as required.
People who maintain third-party SW can react when they are ready, assuming a reaction is required.

07-03-2016, 05:24 AM	#4
chaley Grand Sorcerer Posts: 12,449 Karma: 8012886 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	When considering what is the "hard part", also bear in mind that adding a datatype is likely to break any third-party tools that directly read the calibre database or calibre .opf information. One example class of such tools are the alternate content servers. In addition, this kind of change is arguably like a schema change and not backwards compatible, preventing people from downgrading if required or from running both calibre V(current) and V(old) because their hardware requires it. For this new datatype, plaintext, a much less risky approach would be to add 1 or 2 new booleans to the "display" for comments: "is_plain_text" and (possibly) "show_label". Column writers (and there aren't many of those) would need to be sure that they don't "html"ify the contents and present an appropriate editor to the user. Column readers might need to check, but given that it is currently possible that a comments column contain plain text, it isn't clear how often such a check is required. SW that copies column data (e.g., OPF stuff) probably need no changes at all. This approach has several large advantages: There aren't two column types that are largely the same thing. This is one reason I probably should have implemented the enumerated type using the display instead of as a distinct datatype. Clients who read the database won't break. In rare cases they might show the data incorrectly (e.g., embedded text that looks like HTML), but that is more acceptable than falling over dead. Clients that care about the semantics of the new booleans can adapt their behavior as required. People who maintain third-party SW can react when they are ready, assuming a reaction is required.