Can I hold a reference to .model() and .db in a plugin?

[kiwidude]

To access the data model and database/caches from a plugin, it appears you use self.gui.library_view.model() and self.gui.library_view.model().db respectively.

For coding purposes I usually want to hold a shortcut reference to that such as: self.db = self.gui.library_view.model().db to make the code more readable when doing a bunch of db calls.

Would it be valid to set this reference just once for your InterfaceAction class in initialization_complete()? Currently I re-set it in each connected event in response to a user action. The reason I do this currently is sheer ignorance from not knowing if other code in Calibre at some point would change the object reference returned from either .model() or .model().db.

[chaley]

Originally Posted by kiwidude

To access the data model and database/caches from a plugin, it appears you use self.gui.library_view.model() and self.gui.library_view.model().db respectively.

For coding purposes I usually want to hold a shortcut reference to that such as: self.db = self.gui.library_view.model().db to make the code more readable when doing a bunch of db calls.

Would it be valid to set this reference just once for your InterfaceAction class in initialization_complete()? Currently I re-set it in each connected event in response to a user action. The reason I do this currently is sheer ignorance from not knowing if other code in Calibre at some point would change the object reference returned from either .model() or .model().db.

No, you can't cache it. The value of db changes if libraries change. Holding the old one could lead to disaster, writing the former library while (potentially) using data from the new library.

[kiwidude]

Originally Posted by chaley

No. The value of db changes if libraries change. Holding the old one could lead to disaster, writing the former library while (potentially) using data from the new library.

Phew, cool. That makes sense now. I just looked at the repeated self.db = calls in all those action methods and wondered if I was being too conservative.

However that does raise another issue I hadn't considered with my id caches I mentioned in the notification thread. How do I know that the library has been switched in my plugin so I need to invalidate my caches?

[kovidgoyal]

Implement the library_moved method in your plugin

[chaley]

Originally Posted by kiwidude

However that does raise another issue I hadn't considered with my id caches I mentioned in the notification thread. How do I know that the library has been switched in my plugin so I need to invalidate my caches?

When the library is changed, the 'library_changed' method in actions is called. Assuming that your plugin defines an action, you supply that method.

[chaley]

Originally Posted by kovidgoyal

Implement the library_moved method in your plugin

@kovid,

The comment says that the method is named 'library_moved', but the code contains the method 'library_changed'. I suspect that the comment should be changed.

[kovidgoyal]

Done.

[kiwidude]

Durn it, I remember seeing that function months ago in the API and wondering what the use case was for it.

I guess that "could" be used to set a self.db in response to my original question on this post.

Thanks guys.

[chaley]

Originally Posted by kiwidude

I guess that "could" be used to set a self.db in response to my original question on this post.

Nope. Check_library will change the value of db (closing and re-opening) without calling change_library.

You can cache the value of self.gui.library_view.model(). I can't think of any instance where the library_view is replaced.

[kiwidude]

Originally Posted by chaley

Nope. Check_library will change the value of db (closing and re-opening) without calling change_library.

You can cache the value of self.gui.library_view.model(). I can't think of any instance where the library_view is replaced.

Hehe, ok that is good to know. I was trying to hold a .db reference within my cache class but in hindsight that is clearly a very bad idea. Good to know these things *before* releasing a plugin and trashing databases

[kovidgoyal]

Originally Posted by chaley

Nope. Check_library will change the value of db (closing and re-opening) without calling change_library.

check_library was refactored a while ago to call library_changed after it completes (see actions/choose_library.py).

However, I would encourage you to not hold references to the db unnecessarily. Calling self.gui.library_view.model().db is fast enough that as long as you dont have it in an inner loop you wont see any practical performance implications.

[kiwidude]

Originally Posted by kovidgoyal

check_library was refactored a while ago to call library_changed after it completes (see actions/choose_library.py).

However, I would encourage you to not hold references to the db unnecessarily. Calling self.gui.library_view.model().db is fast enough that as long as you dont have it in an inner loop you wont see any practical performance implications.

It wasn't so much for performance reasons as just passing to that class the least scope it needed to know about - an object design choice. Now I'll just pass self.gui from the action class instead and forget about trying to be too clever