Catalog: Yes/No field

silentguy · 10-09-2013, 03:27 PM

When you create a catalog, you can set prefix rules. For yes no columns in can choose 4 values there: "", "true", "false", "unspecified". Some testing showed the the empty string and unspecified are never applied, true means yes and false means no or unspecified. Why is this not handled like the normal search where no means no, yes means yes, false means no value given and true means value give ie yes or no. I would really like to be able to have a way to give a prefix for Yes and another for No, without having the no prefix also apply to the books where read is not set.
Sorry if this is already covered, but yes and no are not searchable in the forum and I'm only posting from my mobile phone which makes using it harder still :-P

theducks · 10-09-2013, 04:49 PM

Quote:

Originally Posted by silentguy

When you create a catalog, you can set prefix rules. For yes no columns in can choose 4 values there: "", "true", "false", "unspecified". Some testing showed the the empty string and unspecified are never applied, true means yes and false means no or unspecified. Why is this not handled like the normal search where no means no, yes means yes, false means no value given and true means value give ie yes or no. I would really like to be able to have a way to give a prefix for Yes and another for No, without having the no prefix also apply to the books where read is not set.
Sorry if this is already covered, but yes and no are not searchable in the forum and I'm only posting from my mobile phone which makes using it harder still :-P

Tristate T/F should have 3 states, not 4

not #read:true returns False or unasigned
#read:true returns (Field 'set") T or F
#read:false returns (Field 'not set") undefined

Sabardeyn · 10-09-2013, 04:53 PM

Silentguy,
I'm sorry, but I'm not sure exactly what issue you are trying to discuss. Perhaps you could re-phrase?

Just in case it's relevant, I know that Y/N can be set to accept a third answer: Null or Unspecified. Allowing for that 3rd answer is done through a Preference or Tweak setting. So if you didn't set it, it might be skewing your results.

silentguy · 10-10-2013, 01:37 AM

Was I being that confusing? Sorry. Okay, let's try this again.

My #read column is a tristate yes/no column and I use all three values. When you search in this column it works like this:

#read:yes finds books where it is set to yes
#read:no finds books where it is set to no
#read:false finds books where it is not set
#read:true find books where it is set, ie where it is yes or no

so far, so good, this is logical and follows the way the search works for any field.

Now for MY PROBLEM: when creating catalogs, there is a prefix option that does not follow this logic. There you have 4 predefined search values and they return the following :
#read:true finds books where it is set to yes
#read:false finds books where it is set to no or where it is not set
#read:undefined finds no books
#read:"" finds no books either.

Long story short, I think there is a small bug in the prefix search.

Sabardeyn · 10-10-2013, 06:13 AM

Thanks for clarifying the problem, but I've got to admit that this issue is beyond my knowledge of catalogs. Hopefully someone else will provide an assist shortly.

theducks · 10-10-2013, 09:46 AM

Quote:

Originally Posted by silentguy

Was I being that confusing? Sorry. Okay, let's try this again.

My #read column is a tristate yes/no column and I use all three values. When you search in this column it works like this:

#read:yes finds books where it is set to yes
#read:no finds books where it is set to no
#read:false finds books where it is not set
#read:true find books where it is set, ie where it is yes or no

so far, so good, this is logical and follows the way the search works for any field.

Now for MY PROBLEM: when creating catalogs, there is a prefix option that does not follow this logic. There you have 4 predefined search values and they return the following :
#read:true finds books where it is set to yes
#read:false finds books where it is set to no or where it is not set
#read:undefined finds no books
#read:"" finds no books either.

Long story short, I think there is a small bug in the prefix search.

See post #2 (i used a generic #name in the example because there are MR readers that abhor having field names dictated to them)

Empty Quotes will not work on a logical field, they are not nil strings

silentguy · 10-10-2013, 09:55 AM

Quote:

Originally Posted by theducks

See post #2 (i used a generic #name in the example because there are MR readers that abhor having field names dictated to them)

Empty Quotes will not work on a logical field, they are not nil strings

AGAIN: I'm not talking about a search I made, I an talking about predefined options. I did not expect the empty string to do anything. My problem is that the PREDEFINED possibilities do not cover all cases and are generally misnamed compared to the search.

And your example is really hard to get. Still don't get what you were trying to tell me, and I had logics as part of my computer science degree ;-)

Sabardeyn · 10-10-2013, 02:31 PM

Silentguy,
Are you talking about this: Calibre Manual: Creating AZW3, EPUB, MOBI Catalogs>Prefixes? (I know that seems like I'm asking you to repeat yourself, again. But I'm ignorant here so I'm trying to make sure we're talking about the exact same thing.)

So what I think you're saying is, when it comes to Prefix tests, and values returned by them, the results should be:

Missing test: #read:yes (which would find all yes/true values)
Missing test: #read:no (which would find all no/false values; but not null/unspecified)
Incorrect logic: #read:true (which should return yes/true if a Y or N value is present; false if null/unspecified)
Incorrect logic: #read:false (which should return yes/true if there is a null or unspecified value only; false if there is any other value present)
Incorrect logic: #read:"" or Undefined (which should return the same results as #read:false)

Did I get any part of that correct? If I did not, could you just state which test # is wrong?

I still think this has (peripherally) to do with the decision to go with a tri-state Y/N field. I vaguelly recall that there was some question about logical comparison's at that time, but I cannot recall any other details.

Edit: AHA! My Search-Fu is strong today! Possibly relevant topics:
Opinions wanted on details of new GUI features
Default value for read field (Yes/No-field)
default value for defined y/n column

silentguy · 10-10-2013, 04:13 PM

Quote:

Originally Posted by Sabardeyn

Silentguy,
Are you talking about this: Calibre Manual: Creating AZW3, EPUB, MOBI Catalogs>Prefixes? (I know that seems like I'm asking you to repeat yourself, again. But I'm ignorant here so I'm trying to make sure we're talking about the exact same thing.)

So what I think you're saying is, when it comes to Prefix tests, and values returned by them, the results should be:

Missing test: #read:yes (which would find all yes/true values)
Missing test: #read:no (which would find all no/false values; but not null/unspecified)
Incorrect logic: #read:true (which should return yes/true if a Y or N value is present; false if null/unspecified)
Incorrect logic: #read:false (which should return yes/true if there is a null or unspecified value only; false if there is any other value present)
Incorrect logic: #read:"" or Undefined (which should return the same results as #read:false)

Did I get any part of that correct? If I did not, could you just state which test # is wrong?

I still think this has (peripherally) to do with the decision to go with a tri-state Y/N field. I vaguelly recall that there was some question about logical comparison's at that time, but I cannot recall any other details.

Edit: AHA! My Search-Fu is strong today! Possibly relevant topics:
Opinions wanted on details of new GUI features
Default value for read field (Yes/No-field)
default value for defined y/n column

Your list is pretty much dead on! Well, for 5. I would think that the empty string is some weird default and not returning anything is acceptable. And 1. is only missing in name, cause 3. currently returns what I would expect for 1.
And you guys are correct, used on an two state box it would make sense the way it is, cause the value that is dropped is undefined, which means true=yes false=no is a sensible comparison. But it does not match up with the normal search.

silentguy · 03-20-2014, 02:40 AM

Okay, this feature is still broken, so I guess I'll necro my old thread and add some pictures cause people don't seem to get this.

First, a look at my library. Notice the three test books, markes #read:yes, #read:no, and #read:not_set.

Not I mark those books and tell it to create an epub catalog. this is what the predefined list lets me choose:

And here are the results of using those options:

true:
false:
unspecified:
"":

And to repeat my two problems with this:

This does not match up with the way true and false work in the search box
This does not allow you to properly transfer a tristate flag!

DoctorOhh · 03-20-2014, 05:08 AM

Did you ever submit a bug report? If not learn how here.

silentguy · 03-20-2014, 05:13 AM

Quote:

Originally Posted by DoctorOhh

Did you ever submit a bug report? If not learn how here.

I intended to, after waiting to hearing from the community. But forgot last time

Did so this morning

GRiker · 03-20-2014, 08:02 AM

Patch submitted, should be available in the next release.

G

silentguy · 03-20-2014, 08:40 AM

Just dusted of my old development build I stopped using and tested it. Works almost like expected with the only (cosmetic) problem that it used true and false to represent yes and no which differs from the way the normal search works, but seeing how it's pretty clear how to use it nonetheless I'm now happy

10-09-2013, 03:27 PM	#1
silentguy Connoisseur Posts: 88 Karma: 200 Join Date: Nov 2010 Location: Dortmund, Germany Device: Kindle Paperwhite (10. Generation)	BUG: Catalog: Tristate Yes/No field When you create a catalog, you can set prefix rules. For yes no columns in can choose 4 values there: "", "true", "false", "unspecified". Some testing showed the the empty string and unspecified are never applied, true means yes and false means no or unspecified. Why is this not handled like the normal search where no means no, yes means yes, false means no value given and true means value give ie yes or no. I would really like to be able to have a way to give a prefix for Yes and another for No, without having the no prefix also apply to the books where read is not set. Sorry if this is already covered, but yes and no are not searchable in the forum and I'm only posting from my mobile phone which makes using it harder still :-P Last edited by silentguy; 03-20-2014 at 02:41 AM.

10-10-2013, 02:31 PM	#8
Sabardeyn Guru Posts: 644 Karma: 1242364 Join Date: May 2009 Location: The Right Coast Device: PC (Calibre), Nexus 7 2013 (Moon+ Pro), HTC HD2/Leo (Freda)	Silentguy, Are you talking about this: Calibre Manual: Creating AZW3, EPUB, MOBI Catalogs>Prefixes? (I know that seems like I'm asking you to repeat yourself, again. But I'm ignorant here so I'm trying to make sure we're talking about the exact same thing.) So what I think you're saying is, when it comes to Prefix tests, and values returned by them, the results should be: Missing test: #read:yes (which would find all yes/true values) Missing test: #read:no (which would find all no/false values; but not null/unspecified) Incorrect logic: #read:true (which should return yes/true if a Y or N value is present; false if null/unspecified) Incorrect logic: #read:false (which should return yes/true if there is a null or unspecified value only; false if there is any other value present) Incorrect logic: #read:"" or Undefined (which should return the same results as #read:false) Did I get any part of that correct? If I did not, could you just state which test # is wrong? I still think this has (peripherally) to do with the decision to go with a tri-state Y/N field. I vaguelly recall that there was some question about logical comparison's at that time, but I cannot recall any other details. Edit: AHA! My Search-Fu is strong today! Possibly relevant topics: Opinions wanted on details of new GUI features Default value for read field (Yes/No-field) default value for defined y/n column Last edited by Sabardeyn; 10-10-2013 at 02:50 PM. Reason: Looking for related topics

03-20-2014, 02:40 AM	#10
silentguy Connoisseur Posts: 88 Karma: 200 Join Date: Nov 2010 Location: Dortmund, Germany Device: Kindle Paperwhite (10. Generation)	Okay, this feature is still broken, so I guess I'll necro my old thread and add some pictures cause people don't seem to get this. First, a look at my library. Notice the three test books, markes #read:yes, #read:no, and #read:not_set. Not I mark those books and tell it to create an epub catalog. this is what the predefined list lets me choose: And here are the results of using those options: true: false: unspecified: "": And to repeat my two problems with this: This does not match up with the way true and false work in the search box This does not allow you to properly transfer a tristate flag!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Copy data from Title field to IDs field	rlh3	Library Management	9	09-24-2012 08:12 AM
Field of Life and Field of Mind	newone	Self-Promotions by Authors and Publishers	1	07-23-2012 02:21 AM
Default value for read field (Yes/No-field)	opitzs	Library Management	3	11-09-2011 07:17 AM
mobi catalog = periodical, ePub catalog = book	trekchick	Library Management	7	03-12-2011 01:11 PM
catalog	alansplace	Library Management	8	02-02-2011 10:59 PM

10-09-2013, 04:53 PM	#3
Sabardeyn Guru Posts: 644 Karma: 1242364 Join Date: May 2009 Location: The Right Coast Device: PC (Calibre), Nexus 7 2013 (Moon+ Pro), HTC HD2/Leo (Freda)	Silentguy, I'm sorry, but I'm not sure exactly what issue you are trying to discuss. Perhaps you could re-phrase? Just in case it's relevant, I know that Y/N can be set to accept a third answer: Null or Unspecified. Allowing for that 3rd answer is done through a Preference or Tweak setting. So if you didn't set it, it might be skewing your results.

10-10-2013, 01:37 AM	#4
silentguy Connoisseur Posts: 88 Karma: 200 Join Date: Nov 2010 Location: Dortmund, Germany Device: Kindle Paperwhite (10. Generation)	Was I being that confusing? Sorry. Okay, let's try this again. My #read column is a tristate yes/no column and I use all three values. When you search in this column it works like this: #read:yes finds books where it is set to yes #read:no finds books where it is set to no #read:false finds books where it is not set #read:true find books where it is set, ie where it is yes or no so far, so good, this is logical and follows the way the search works for any field. Now for MY PROBLEM: when creating catalogs, there is a prefix option that does not follow this logic. There you have 4 predefined search values and they return the following : #read:true finds books where it is set to yes #read:false finds books where it is set to no or where it is not set #read:undefined finds no books #read:"" finds no books either. Long story short, I think there is a small bug in the prefix search.

10-10-2013, 06:13 AM	#5
Sabardeyn Guru Posts: 644 Karma: 1242364 Join Date: May 2009 Location: The Right Coast Device: PC (Calibre), Nexus 7 2013 (Moon+ Pro), HTC HD2/Leo (Freda)	Thanks for clarifying the problem, but I've got to admit that this issue is beyond my knowledge of catalogs. Hopefully someone else will provide an assist shortly.

03-20-2014, 05:08 AM	#11
DoctorOhh US Navy, Retired Posts: 9,896 Karma: 13806776 Join Date: Feb 2009 Location: North Carolina Device: Icarus Illumina XL HD, Kindle PaperWhite SE 11th Gen	Did you ever submit a bug report? If not learn how here.

03-20-2014, 08:02 AM	#13
GRiker Comparer of the Ephemeris Posts: 1,496 Karma: 424697 Join Date: Mar 2009 Device: iPad	Patch submitted, should be available in the next release. G

03-20-2014, 08:40 AM	#14
silentguy Connoisseur Posts: 88 Karma: 200 Join Date: Nov 2010 Location: Dortmund, Germany Device: Kindle Paperwhite (10. Generation)	Just dusted of my old development build I stopped using and tested it. Works almost like expected with the only (cosmetic) problem that it used true and false to represent yes and no which differs from the way the normal search works, but seeing how it's pretty clear how to use it nonetheless I'm now happy

Advert

Advert