biblioteq
biblioteq copied to clipboard
textbrowser
Mass Update
Mass update: To be able to select records (with the mouse or the SQL module) and modify a field en masse.
by examples of work to do :
-
I have an isbn13 list of 100 documents and I want to update the binding type to cardboard.
-
after inventory I have the list of all the documents of type "Crime novel"; I want to update the fields "location" and "target_audience".
This is achieved by SQL and is not a responsibility of the application. Custom data transactions require customization which is already provided by SQL for PQ and SQLite. BQ is not responsible for such updates. I'm referring to custom SQL queries in the application. That is mostly read-only.
The UPDATE statement provides plenty of richness for updating data sets. There is nothing gained by placing custom update statements in the software. These additions would simply duplicate PostgreSQL and SQLite. I understand the benefit of applying specific UPDATE statements on selected display items. "For the selected items, apply the following statement." This is nice but essentially duplicates SQL.
I'm thinking more about the usability of the application.
I don't know how to update by sql the proposal of my 1st message.
BiblioteQ users are not all SQL experts and even BQ says Even BQ specifies : This panel is intended for advanced users who have an intimate knowledge of SQL and the database layout of BiblioteQ.
This is not a fault of the application. It's an expectation of the application. There are an infinite number of SQL queries and an application cannot cover them. One purpose of BQ is to educate people in SQL. If someone is interested in their data, then they must assume that this interest requires time to learn how to survey it.
The idea that SQL is a development language is super poor. SQL and an application's usability are separate. Why replicate SQL in the application when there are official interfaces? For easing a person's learning? That's silly. Today, we will remove all mathematics from Quantum Mechanics because Quantum Mechanics is not usable because of them. We want usability!
UPDATE book SET binding_type = 'Binding' WHERE isbn13 IN ('1', '2', '3');
I can explain to the volunteers that they have to go to such and such a menu after selecting the documents to be modified and the software will guide them to update certain fields for example, but I cannot tell them to go and see another tool, to learn the SQL language and then you can do what you want with the database.
As I wrote, I convinced myself of the perceived benefits. A know-it-all program.
However, it makes people stupid.
I would work on a solution to help people with mobility problems. But no one has asked for that. Complex shortcuts are cheats. I understand the benefits. :) You need to convince me that I should find these gimmicky SQL statements interesting to me because I would implement them.
Is it better to master a program that makes you stupid or to know how to use 10 percent of a program that makes you smart?
You're asking me if I should read a book or its Cliff Notes counterpart?
I think you have identified the problem. but a little clarification, the book is in a field that does not interest you.
The end result is that the person learns nothing and I learn nothing. No one learns.
You are not in the same frame of mind as the library volunteers.
-
I agree that for you, learning is non-existent because you know it all, but you are doing the library volunteers a favor.
-
The volunteer gives his time so that the population can have a local library.
Their needs are not to learn computers but to have a software that manages the library and its loans, to welcome people, to go to the bookstore to buy books, to cover the books, to classify the books, ...
it's people like you who give their time for others but in a different field.
And that's why my position is clearer. I'm looking for a future gain: learning. Not a quick gain: satisfying the volunteer.
There's a really helpful outcome when a person learns how to do something for themselves, especially with technology.
"Apply specified query to selected entries."
That's a grand plan which requires the person undertaking it to understand the query, the data, and the mechanisms to create a meaningful relationship between the two. Even a descriptive text will not be sufficient.
For example, suppose you create a query which modifies several fields for selected items which have other criteria. Like, set the binding if the ISBN is within this set and if the item has also a publication date within a range. Your query naming will require specific text to inform the person applying it. That descriptive text may be totally useless if the person does not comprehend the SQL.
I thought that sql was a plus for the program because it allowed to do things not foreseen by the graphical interface for the specialists.
now I think the opposite
The sql replaces the GUI and asks users to know the kitchen without them wanting to know it and to do things that are fairly simple from the user's perspective).
for standard use : UPDATE book SET binding_type = 'Binding' WHERE isbn13 IN ('1', '2', '3'); ?
You is referring to the custom SQL? That is for SQL-literate people. Since I'm kind of SQL literate, I thought that such an interface would be beneficial to other people. See? If you become aware of something, you're more likely to publish that interest to others so that they become interested in it. If SQL does not interest you, the language continues to attract only people who are interested or require it. The language remains specialized. More on this discussion for another day.
Neither BQ nor SQL replace each other. They co-exist. My question to you is not to hide the SQL, but to allow people to learn it and to think about the problem of providing clarity to custom commands if those custom commands are provided to people who are SQL illiterate. "Press this button to do something with the data. Because you don't understand the mechanisms behind the function, just trust us."
That I am interested in SQL and that I discover it thanks to BQ and its SQL is great (many thanks to you)
But don't forget that I am testing BiblioteQ for the people in my library. (some of them don't know how to open the windows command prompt)
If they know how to use the GUI version of BQ at 60-70% of its possibilities it will be great. Nobody in the 9 volunteers has the technical profile so the GUI version should allow to manage a library with the maximum of possibilities.
even with a GUI version of this feature (UPDATE book SET binding_type = 'Binding' WHERE isbn13 IN ('1', '2', '3'); ) could be a source of error with a wrong selection of documents
Press that button to do something with the data. Since you don't understand the mechanics behind the function, trust us."
this is the advantage of open software whoever wants to see the recipes, has the possibility to do so the one who wants to make it work, has the possibility to do so
It's not a problem, it's an adventure and it exists in all disciplines.
This can be solved by allowing update queries in Custom Query. It would require that MYOID values are available in the current view which they are unless another custom query was recently executed and the custom query did not include MYOID values. Not sure about complex update statements. The statements would need to be rudimentary. This is actually a simple problem as long as it doesn't require a sophisticated solution.
- Select some items.
- Define a custom query. Example: UPDATE book SET binding_type = 'Value'. Notice that the query does not include a WHERE clause. If a WHERE clause is included, the query would work but would ignore the selected items.
- Save custom query.
- Execute custom query.