db update urls whilst retaining tags

[plum]

No description provided.

[plum]

With buku -u --tacit my user-defined tags were added to from the title. I have 5,000 urls in the DB. That gave me a list of tags almost as long as the indices!
From my reading of the man page, this is not supposed to happen, as I understand it.
How could this have happened, and what could can I do about it? (it's OK I have a backup).

I'll test again on a smaller set.

[plum]

This is the orignal test scheme:

$ buku -t
     1. battery (19)
     2. charger (19)
     3. electronics (19)

And following $buku -d tacit,

$```
 buku -t
     1. 12v (1)
     2. 6v (1)
     3. android apps (1)
     4. battery (19)
     5. charger (19)
     6. electronics (19)
     7. free apps (1)
     8. free games (1)
     9. free software (1)
    10. freeware software (1)
    11. linux software (1)
    12. motorbike battery charger (1)
    13. online apps (1)
    14. os x software (1)
    15. scooter battery charger (1)
    16. windows software (1)

[jarun]

I think you referred to example 12. It's a mistake on our part. The latest version updates all the fields. The behaviour was updated here:

https://github.com/jarun/Buku/wiki/Operational-notes#update

But not on example 12. I will update that.

Note that we have a line item to disable update of individual fields.

[jarun]

Description fixed at commit 5df231947392475ced257a6ba5e4cec3c3fbb5a9.

[plum]

Thanks.
Does that then mean that,
1, I cannot update the whole database without losing user-defined tags?
2. I can update a range of bookmarks and keep user-defined tags?

[plum]

Also, can you give an example of how I can query a user-defined tag and update that set, wihtout losing the tag?

• because without that facility, I cannot continue to usefully use buku, whereas otherwise it's brilliant.
  Thanks, John

[jarun]

I cannot update the whole database without losing user-defined tags?

tags are appended, older tags are not lost

[plum]

yes true, but as you can see from the results given above, with a large collection especially, the recorded tags are chaotic and --stag returns chaotic results; Tags appended from titles do not necessarily give meaning to the user. In the example above I get 'windows' software' , 'free sofware' etc, for what is in fact a simple electronics power board. Tghe tags multiply insanely, and I cannot see to select my user-defined titles. The imposed tags are an obfuscation.
`It really makes no sense because, in any case titles remain as an option to search - so the update that way by default is useless, and chaotic.

[plum]

Can you give an example of how I can query a user-defined tag and update that set, without losing the tag?

[plum]

I tried:
buku -u --stag electronics
but I get the same result with same extra tags appended.

[jarun]

Tags appended from titles

not from title, they are from the page data.

I mentioned that we have a line item to give more granular control. Please wait for that to come in or raise a PR if you need it right away.

[plum]

OK. Thanks.

[plum]

Checking out the line items, I found it as: Add option --preserve to ignore specific fields during auto-update [see API update_rec() and issue #327].
I myself am not ably prepared to tackle this issue with a pull request - I think its out of my depth without significant advance preparation, it being outside my programming scope at this time.

I can give you a further idea of how, without it a user runs into significant trouble:
updating a subset of my urls, with 100 urls and 73 user-defined tags results in 5,020 additional tags form metadata! Many are over-generalised, meaningless, or rubbish. These render the tag list almost useless.
It may be born in mind, and It occurred to me that, within decent computer programming sites, metadata is entered carfeully and titles too. Words have to be very spcific to convey accurate meaning in programming.
In contrast, in fields of social, cultural human interest, politics and poetry enter the descptions, where words are politicised, meanings stretched etc.. Also, webmasters endeavour to write in 'catchall' words hoping to grab attention in search results. And so forth.
Private or sole-use computers tend to combine computing interests with others in the more political-social fileds, and their bookmarks will reflect this. They need to retain purely user-defined tags.
Regards,
John

[jarun]

OK. Thanks for explaining.

[jarun]

I have added a patch to master to disable updating tags from the page. Even the tags of my bookmarks have gone for a toss.

Please test and confirm. Thanks for the report!

[plum]

Thanks for kind consideration Jarun. I ran the latest from git today with success regarding keeping user-defined tags when updating selected url as follows
$buku -u XXXX

The command above updates the title but leaves the user-defined tags in place without any additions from the hosted web page.

The behaviour is particularly useful. You say the 'tags of my bookmarks have gone for a toss'; i guess you mean you have gone for this behaviour at the expense of any method to fetch tags from remote page in any way (at this time). That's a sacrifice, know, but possibly the best way forward; a method could now be devised to run with specific option to add to tags form remote page, rather than by default.

Further Observation:

Am I right in beleiving that titles cannot be made immune from updating, without re-entering a user-defind title? If so, that's not so bad, all in all, as opposed to the case with tags. Example:
Wordpress returns the title of 'Wordpress.com' for any particluar blog's stats page, nothing else. If desired as a help, a user may define the blog name in the title, but that gets lost on update. However, it does remain in the url, so no real hardship there.

THanks,
JOhn

[jarun]

Yes, the titles would be updated. However, you can mark a bookmark as immutable and in that case no field would be updated.

Wordpress returns the title of 'Wordpress.com' for any particluar blog's stats page, nothing else

Can you please share an example link?

[plum]

Sure. Here:
https://wordpress.com/stats/jakbop.wordpress.com
Yes, I can mark it as immutable. I dont fully understand that though. During a 'web fetch' with the update option '-u' to 'refresh' , and with the immutable option '-N' for a particulalar url, rather than batch, what if anything gets 'updated'/'refreshed'.
[NOTE: I am supposing 'auto-refresh' in the man pages under '--immutable' EDIT OPTION refers to 'update fields' mentioned in '--update' GENERAL OPTION]

[jarun]

Can't access the stats page but I can see if I add the home page the title is fetched correctly:

$ buku -a jakbop.wordpress.com
488. uNbound | A great WordPress.com site
   > jakbop.wordpress.com
   + A great WordPress.com site

[plum]

Yes, that's true the home page when updated returns a nice, fully descriptive title, in this case. That is, a page for public view. The admin stats page for the blog (useful for admins!) doesn't... and so this is just one example of how titles and their usefulness vary from one server impplementation to another. It's a small point - an observation.

~As I say, I think the tags behaviour mow, is much better for general buku usability, as per previous observations concerning tags. Titles, and urls, fetched from web behave much better, are more useful as is.