Closed meteos77 closed 1 year ago
Do you need editable Condition and Originality for books? That's my interpretation of the discussion.
BQ has an originality field that is blocked with 2 copies W/B and colors and origin
as a library we only have originals. so if the "originality" field became more open to modification, I could use it to store "provenance". ( ex : book purchase , donations , loan-2015-12 , loan-2022-12)
Concerning the condition field, it is also blocked with your typical values. if it became more open, it would correspond more to our criteria. Hence my request to have rich fields (with enumeration database) that let the user define his own typical values.
I like in biblioteQ the relation between the database enumeration and the pop-up it makes filling and searching easier because the values are free and at the same time directed enough to have the most homogeneous database possible.
Will add new condition and originality enumerations. The interface fields will remain as they are.
Target Audience is an exception as it's editable.
I don't use the editing feature because it prevents me from using the search function after
What do you mean?
It works.
if I edit in the popup (book edition) UNKNOWN to UNKNOWN2 I can't search for it because UNKNOWN2 won't be present in the search popup
the direct modification in the field is a freedom I don't use for target_audience. In fact it is this feature that I would have liked to have for custom queries :-)
I knew you were going to say this!
So. The editable Target Audience field implies that your new value is only applicable to that particular item and should not be part of the enumerations table. This is a natural and clear understanding because you're applying an exceptional value. The belief that all values should be available in the combination box for a search function is... exceptional. BQ would have to detect all distinct values from all books and populate the widget while also retrieving the enumerated values.
The editable field implies that your particular value is specific to that book. If it is not, enumeration! If you're interested in the unique values in future searches, custom query will aid.
I didn't want an editable field and if I did, I was a moron. It's not a suitable property because an enumeration exists. It added complexity and confuses you.
in any case, I prefer the easy search with popup near-configured by enumeration database than to make SQL queries to see where the execeptions would be hidden the library people want simple actions
Target Audience is an exception as it's editable.
I think I finally understood your phrase :-)
tell me if it is good : the field is not managed in a table of the database but in another way while all the others are.
in any case, I prefer the easy search with popup near-configured by enumeration database than to make SQL queries to see where the execeptions would be hidden the library people want simple actions
Libraries catalog human culture. The expectation that the software and science which aids in that act should be simple is absurd.
I want to go to the Moon and I want a simple and safe solution. Simple before safe.
Library managers are not computer people but rather literary people. You can drive an everyday car without wanting to drive a Formula 1 car.
BiblioteQ is successful with its GUI that makes it easy to use and the pros can use SQL to do more.
If you want richness, you're going to have options. But you see, you asked for an editable target audience and are confused of the results because you didn't understand your original request. Perhaps you understood it and expected that the software should perform an additional query.
So here's the thing. If you have 10,000 target audiences, there's an expectation that those will be shown somewhere. So here's the other thing. If you have hidden audiences, that expectation that they'll be gathered and shown is not a natural expectation. Like if I'm going to look for a specific book or a set, I don't expect a weird field that I'm not using to be populated with items that are hidden.
Having 10,000 audiences or any other burdensome enumeration is also moronic. Your database should not house values that will burden the processes of searching for values. Retrieving and populating 10,000 items is not wise. There's a reason, for example, there are categories within categories instead of a single category housing a union of sub-categories. Enumerations need to be mindful of practical purpose. If they're not, they're nuisances.
Imagine a book's index that has the indefinite article an as an entry. You'd go insane.
the librarian has to answer quickly to can you tell me if you have a children's book about this subject.
or do you have other books by such authors because I enjoyed this one.
You can do both in BQ. BQ has embedded hyperlinks yo! Hyyyypeeeeeerrrrrrrrlinks. It's wild.
we already talked about hyperlinks but I never managed to make one.
Hyppppppppppperlinks. You can visit another galactic galaxy.
anyway BQ is magic, if I look for a title with an article the or a it takes only 1 second to find 520 documents
Is hyperlinks reserved for PostgreSQL users?
PostgreSQL has a non-editable view mode while SQLite does not. I don't know if it's possible to implement editable hyperlinks. I think it is but would require fields detect immediate revisions.
Maybe not immediate. Maybe after the Return key is pressed.
I didn't get all of them :-) if you have a small link to PostgreSQL for my info
Both are unique and necessary. PQ sounds nicer than SQ.
I knew that PostgreSQL had additional possibilities, you pointed this out to me at the beginning.
We don't have the possibility to manage this possibility.
I will test for my pleasure BQ/PostgreSQL as soon as I have a moment to know the differences between the 2.
Oh yes you do! Locally right there on the laptop or desktop computer. It'll listen on 127.0.0.1:5432. Or, like previously discussed, on a Pi connected directly with the laptop / desktop and powered by USB. Super. Complete. Happy.
who manages it in case of problems?
it is not a material problem with the PI but a human resource problem we are volunteers, 1 person per shift, 9/10 who know almost nothing about computers
the following request is already difficult: create a text file on the desktop and scan the isbn13.
you see the difficulty.
who manages it in case of problems?
The database? People do. Or, purchase PostgreSQL support.
Will not be addressed this year. Perhaps mid 2023. Too many requests.
Start of 2023, maybe. Yah, too many requests. Remember, hobby.
My requests are related to the discovery through the use of BiblioteQ as the SQL.
It will take as long as it takes you and your desire. I never forget that this is one of your many hobbies.
THANK YOU FOR ALL that you have already done
Please test the new condition and originality enumerators.
Great thanks a lot according to my tests it works well
can you add the option automatic creation of values in enumeration database for the field: originality (like for location). If it doesn't take too much time of course thanks in advance
Location is a pair. Condition and originality are singletons of books.
I'm not adding default values because of translations and because that's the entire purpose I spent time to do this change.
You can add default values because it's your data.
ok, I think I understood the difference between location and the rest which is specific to a category
this will make me an SQL exercise : to find the non present in the enumerations :-)
You're going to ask for import changes too.
to manage the documents properly, we would need 3 additional fields:
thank you in advance