[FileType Plugin] GetFileName

[Terisa de morgan]

I'm updating the config like this:

		
  from calibre.library import db as db_

  db = db_()

  db.prefs.set_namespaced(PREFS_NAMESPACE, PREFS_KEY_SETTINGS, library_config)

As in the other plugins (not the first part). I'll try to find the config API.

[kovidgoyal]

That is the correct API. And it does update both in memory and in db copies. See line 126 of backend.py in the calibre source code.

[kovidgoyal]

You are again creating a new db copy. Dont do that. Use the existing db object. If you create a new db copy, the in-memory representations of the preferences are not synced between copies.

[Terisa de morgan]

Originally Posted by kovidgoyal

You are again creating a new db copy. Dont do that. Use the existing db object. If you create a new db copy, the in-memory representations of the preferences are not synced between copies.

Problem is, I cannot use it (or I don't know how to access it), as in this case there is no db in the call (FileType plugin)).

[kovidgoyal]

You should not be accessing the db in any filetype callback other than postimport and postadd. The other callbacks can be called in contexts where the db is unavailable/locked.

If you need to store some config options that you need in those callbacks use a config file, dont store them in the db.

[Terisa de morgan]

Originally Posted by kovidgoyal

You should not be accessing the db in any filetype callback other than postimport and postadd. The other callbacks can be called in contexts where the db is unavailable/locked.

If you need to store some config options that you need in those callbacks use a config file, dont store them in the db.

Yes, I'm understanding this, and I must store the configuration for each library in the file, yes.

[BetterRed]

Originally Posted by Terisa de morgan

Yes, I'm understanding this, and I must store the configuration for each library in the file, yes.

So %CALIBRE_CONFIG_DIRECTORY%\plugins\getfilename.jso n, would have something like:

"Journals": {
    "customColumnPath": "", 
    "opcName": "path", 
    "custonColumnExtension": "", 
    "customColumnName": "#camefrom", 
    "customColumnDate": "", 
}
"Media": {
    "customColumnPath": "", 
    "opcName": "name", 
    "custonColumnExtension": "#orig_ext", 
    "customColumnName": "#orig_name"
    "customColumnDate": "#orig_mod_date", 
}

If a library is renamed the plugin will probably stop saving the file details - as happened to me last December? If the user doesn't show the columns in the book list or book details sidebar it could be weeks or months before they noticed - I didn't notice until late January.

BR

[kovidgoyal]

It's not clear to me why config about which column to store filenames in needs to be accessed outside of postadd/postimport.

[Terisa de morgan]

Originally Posted by kovidgoyal

It's not clear to me why config about which column to store filenames in needs to be accessed outside of postadd/postimport.

You have to define the columns at some point but I've changed the way it's managed (it has to access to the database to get the custom columns, it cannot be avoided, but that's all).

[Terisa de morgan]

Originally Posted by BetterRed

If a library is renamed the plugin will probably stop saving the file details - as happened to me last December? If the user doesn't show the columns in the book list or book details sidebar it could be weeks or months before they noticed - I didn't notice until late January.

BR

In a file? Yes, that's one of the reasons I wanted to store it in the database but it looks like it cannot be avoided, and I see no way to correct this (anyway, to rename a library is not a common event).

[BetterRed]

Originally Posted by Terisa de morgan

In a file? Yes, that's one of the reasons I wanted to store it in the database

Appreciate that, like all the other PIs that have column lookup names in their configurations - View Manager, Count Pages, Reading List, etc.

Originally Posted by Terisa de morgan

but it looks like it cannot be avoided, and I see no way to correct this (anyway, to rename a library is not a common event).

I guess it's because it's a File Type plugin, the others are User Interface plugins.

A safer way would be to impose a 'restriction' that the configuration of GFN will apply to all libraries - if the nominated lookup names are present they will be populated, otherwise they won't.

BR

[Terisa de morgan]

Originally Posted by BetterRed

Appreciate that, like all the other PIs that have column lookup names in their configurations - View Manager, Count Pages, Reading List, etc.


I guess it's because it's a File Type plugin, the others are User Interface plugins.

Yes, a GUI plugin has a direct access to the database at any moment, a file plugin no.

Originally Posted by BetterRed

A safer way would be to impose a 'restriction' that the configuration of GFN will apply to all libraries - if the nominated lookup names are present they will be populated, otherwise they won't.
BR

I don't like it. I would prefer, if necessary, a default configuration which will apply if no library is found, but no restriction of the same configuration for every library.

[BetterRed]

Originally Posted by Terisa de morgan

Yes, a GUI plugin has a direct access to the database at any moment, a file plugin no.

Devil's Advocate asks, "Why not? And could it be made so? And if not, why not?"

BR

[kovidgoyal]

Originally Posted by BetterRed

Devil's Advocate asks, "Why not? And could it be made so? And if not, why not?"
BR

Because they can run in places where there is no db, such as the command line tools on a system with no library.

@Terisa: All libraries have a unique id, independint fo the name.

db.new_api.library_id

Although, if I were you, I'd just not bother with configuration at all and just have it store the data in any custom column named #filename/#filepath. Then its up to the user to create such a column.

[Terisa de morgan]

kovid, that would solve the problem, thank you very much. And I already have done almost all the work, so I think I'll introduce this small change and that's all, it would be more work going your approach now.