|
|
Yes, I can confirm that the values are cached, so if there is already a track instance in memory cached then this instance is used (instead of reading from DB again). I believe that this used to be the case in MM4 too, but probably not so noticable as in MM5 the unused tracklists are cached e.g. for minute (just in case a user returns to the previous view in a while) and probably also the garbage collector might not free it immediatelly. So in your usecase above you should rather use something like this: var list = app.db.getTracklist("SELECT * FROM Songs WHERE ID = 1", -1); await list .whenLoaded(); listForEach( list , (itm) => { itm.title = 'BlahBlah'; }); list.commitAsync(); // saves the metadata to the DB and file tag This way you are sure that the new title is written to the file tag also + reflected everwhere in the UI where this track instance(s) are used. Alternativelly I could introduce a new method like app.db.clearSharedObjectsCache() that would force re-reading all the metadata from the DB (having performance penalty of course) that could be used by scripters to clear the memory cache (after modifing DB). The cons would be possible data loss for uncommited data. But ok, let's suppose that it is scripters responsibility / user risk. |
|
|
As I said, I have add-ons that are doing massive changes on the database: 1. It is not about one or two or ten or even a hundred tracks, but maybe a whole library, so executeQueryAsync is a way faster than getTracklist(), than itm.title = 'BlahBlah';, than commitAsync(); 2. I am doing changes not only on Songs table, but on other tables as well, so the getTracklist() is unusable. 3. I am using the combination of several executeQueryAsync and getTracklist methods that are all interconnected and directly dependent. Restart of the program after each such command is out of question. It would be the same as if you require from users to restart the program after each change in the Properties dialog. 4. Changes made by executeQueryAsync are not reflected even to deleteFolderAsync, which could lead to the unwanted removal of media files and/or records from the Songs table (I mentioned these problems in (https://www.ventismedia.com/mantis/view.php?id=19157). So, it would be really nice if you add the mentioned method for clearing the cache. I am not sure about what "possible data loss for uncommited data" you are talking about. Aren't all data committed to db before use of executeQueryAsync? |
|
|
OK, I can add the method for clearing the cache. As for uncommited data: I mean e.g. cases when user edits Properties of a track and did not press [OK] button of the Properties dialog yet. But OK, this is mostly probably unrelated to your scripts as I suppose that user does not perform edits when running your scripts? in addition edits that do not need confirmation are commited as soons as possible. |
|
|
No, my scripts are not running when user has opened Properties or any other modal dialog box. At least not the one that is almost finished and waiting for your update. But if they are running in background, I could warn users that they need to stop any editing. One question about suggested new method. Should I call it after each executeQueryAsync and before each getTracklist or deleteFolderAsync or any other method that read data from cache? Or it will be sufficient to clear cache on the start of series of these commands? As I said, I have many such methods executed in series, both executeQueryAsync and getTracklist intertwined, and it would be most practical if I could use such clear method just once on the start of such series. |
|
|
I am just wondering, could you do something with the beginTransaction/commitTransaction, instead of adding a new method? For example, the cache could be cleared on beginTransaction, and after that the other commands including getTracklist will not read data from the cache but directly from the database, until commitTransaction when you could save database to the cache again. |
|
|
I'll introduce the clearDataCache method into next build, example: // navigate to Music > All tracks await app.db.executeQueryAsync("UPDATE Songs SET SongTitle = 'BlahBlah' WHERE ID = 1"); await app.db.clearDataCache(); uitools.refreshView(); // to reload the tracklist |
|
|
Finally calling it just clearCache, added in 5.0.4.2652 image.png (29,496 bytes) |
|
|
Thanks! |
|
|
Just to mention few issues (trying to update drives/paths by SQL): 1. uitools.refreshView() after app.db.clearCache() works very rarely when called from dialog box; 2. it doesn't update paths of files previously placed to Playing list when drive is changed by SQL; I am using app.player.getSongList().notifyChanged(), but it updates paths only if it is applied after selecting a node with the updated drive. I have implemented a workaround for that in my script, but it would be nice if you resolve this somehow in the program. |
|
|
Open the program with empty database, add one test track and select Entire Library / All tracks node. Here is the same example code: await app.db.executeQueryAsync("UPDATE Songs SET SongTitle = 'BlahBlah' WHERE ID = 1"); await app.db.clearCache(); uitools.refreshView(); When executed from the dialog box, the track in the main tracklist is not updated. However, there is still even more serious issue with deleteFolderAsync that I already mentioned: 1. open the program with empty database and add one test track with the following path c:\Music\Test.mp3; 2. select Entire Library / All tracks node and make sure that the program shows that path; 3. a) move that file to c:\Temp\Test.mp3 using any external program, e.g. Total Commander; or 3. b) execute this: await app.filesystem.renameFileAsync('c:\\Music\\Test.mp3', 'c:\\Temp\\Test.mp3', false /* no overwrite prompt */); 4. execute this from the main window: await app.db.executeQueryAsync("UPDATE Songs SET SongPath = ':\\Temp\\Test.mp3' WHERE ID = 1"); await app.db.clearCache(); uitools.refreshView(); await app.filesystem.deleteFolderAsync('c:\\Music\\', false /* no recycle bin */, true /* only if empty */); and you will get removed the record about that track from the Songs table, even when its path is updated having a new folder. The log file attached. deleteFolderAsync.log (7,721 bytes) |
|
|
I though that this new clearCache method will prevent deleteFolderAsync from removing records from the Songs table, but it is not. I have another workaround for this, but I am sick with all these workarounds. Especially when sometimes they don't work and users blame me for your quirks. |
|
|
Re the refreshView in dialogs. Yes, refreshView is called in the window context, so use code like this to update it in the mainWindow (from which the dialog was called): uitools.openDialog('dlgPodcastSubscription', { modal: true, podcast: podcast }, function (dlg) { uitools.refreshView(); }); Re the issue with app.filesystem.deleteFolderAsync : You forgot to update Songs.IDFolder --> this is the reason why the song entry was deleted. EDIT: Using renameFiles will workarond it: https://www.mediamonkey.com/docs/api/classes/Filesystem.html#method_renameFiles as it takes Tracklist as param (taking care of all the SQL updates automatically). Tip: Move discussions like this to the addons dev forum where others can also join the discussion: https://www.mediamonkey.com/forum/viewforum.php?f=27 |
|
|
Of course I am using refreshView as in your example, but there are situations when you want to update the main window from dialog box, e.g. if it is modeless. I don't want to use renameFiles because it cannot move non-media files, which I have already reported (0019103), and that doesn't resolve a requisite to update paths after moving files outside of the program. And I don't want to mess with the Songs.IDFolder and Folders table. They are automatically updated by the program after my workaround. I suppose it is caused by update_songs_songpath trigger. |
|
|
clearCache verified 2661 Closing as like @ludek said in 0019156:0068826 rest of talk should be in devs forum. |
- Anonymous
