MKMTool ist a helper application I wrote for tinkering around with optimization of sale processes on magiccardmarket.eu and the idea of automisation of some tasks most people wouldn’t be able to get done by pure manpower.
I have made several new features or updates of existing ones and some bugfixes. I have compiled the binaries, uploaded them to my github and changed the link in readme. Most of the new bigger features are based on processing lists of cards loaded from CSV. For that I created the MKMMetaCard for representing any card as a set of some attributes with string values. The card can exist even if defined only partially - I went for robustness rather than efficiency so that new features can be easily added in the future without the need to change a lot. So instead of copying the structure of the XMLs MKM is using, there is only one array of attributes which can contain anything so that we can do "for each attribute" withough having to know what the attributes are and what is their meaning --> we can import & export in whatever format the users are using for their cards.
The Readme has a log of all the changes + documentation for all the new features, so I'm not going to repeat them here and I left enough info in individual commit messages about code changes, but here are some bigger general changes in the codebase:
1) The database is now managed in a more efficient way: I created an MKMDbManager class which is a singleton that once created loads the "inventory" database and also "expansions" and keeps them in memory for as long as MKMTool is running. Before, expansions were always fetched from MKM, but that used API call and also potentially could lead to some inconsistencies like looking for cheap deals from a new set for which our inventory database has no cards. Now they are always synchronized.
Since the database is loaded from the files only once, I am loading them directly from the .csv files rather than the sqlite database. This means that the sqlite file is actually never used. I kept the code that creates the file since I don't know if you're not using it maybe for other software, but technically it is no longer needed. It would probably be slightly more efficient to be loading it from the sqlite file, but I don't think it matters too much and I like having the files in a human-readeable format.
When the databases are being loaded, I check if they are older than 100 days (based on their "file modified" date) and if so, automatically update them. There are also several methods for making select queries from them which always try to update the database if the query does not find anything and the database is more than 24 hours old. I wanted to not expose the DataTables themselves and have them be accesible only through those methods, but then it would be unwieldy to do the JoinTable calls used for example by Wantlist Editor, so they are directly accesible, but the preferred way to get data from them is to use the Get*** methods.
The expansions database now has one more column - releaseDate.
2) I changed the MainView to be a singleton so that its instance is easily accesible from everywhere mainly because I was getting tired of how complicated is the syntax to write a message into the main window from a child thread, so this is simplified now. I have also made the "module" windows "kind of singletons" in the sense that the MainView keeps one instance of them all the time and the buttons just show or hide them. This way we no longer have to show them as blocking dialogs, so that you can have a window opened and still scroll through the log.
I have tested all the modules and they seem to be working correctly, although I have not tested all combinations of all parameters, so there might be some errors.
Hello,
I have made several new features or updates of existing ones and some bugfixes. I have compiled the binaries, uploaded them to my github and changed the link in readme. Most of the new bigger features are based on processing lists of cards loaded from CSV. For that I created the MKMMetaCard for representing any card as a set of some attributes with string values. The card can exist even if defined only partially - I went for robustness rather than efficiency so that new features can be easily added in the future without the need to change a lot. So instead of copying the structure of the XMLs MKM is using, there is only one array of attributes which can contain anything so that we can do "for each attribute" withough having to know what the attributes are and what is their meaning --> we can import & export in whatever format the users are using for their cards.
The Readme has a log of all the changes + documentation for all the new features, so I'm not going to repeat them here and I left enough info in individual commit messages about code changes, but here are some bigger general changes in the codebase:
1) The database is now managed in a more efficient way: I created an MKMDbManager class which is a singleton that once created loads the "inventory" database and also "expansions" and keeps them in memory for as long as MKMTool is running. Before, expansions were always fetched from MKM, but that used API call and also potentially could lead to some inconsistencies like looking for cheap deals from a new set for which our inventory database has no cards. Now they are always synchronized. Since the database is loaded from the files only once, I am loading them directly from the .csv files rather than the sqlite database. This means that the sqlite file is actually never used. I kept the code that creates the file since I don't know if you're not using it maybe for other software, but technically it is no longer needed. It would probably be slightly more efficient to be loading it from the sqlite file, but I don't think it matters too much and I like having the files in a human-readeable format. When the databases are being loaded, I check if they are older than 100 days (based on their "file modified" date) and if so, automatically update them. There are also several methods for making select queries from them which always try to update the database if the query does not find anything and the database is more than 24 hours old. I wanted to not expose the DataTables themselves and have them be accesible only through those methods, but then it would be unwieldy to do the JoinTable calls used for example by Wantlist Editor, so they are directly accesible, but the preferred way to get data from them is to use the Get*** methods. The expansions database now has one more column - releaseDate.
2) I changed the MainView to be a singleton so that its instance is easily accesible from everywhere mainly because I was getting tired of how complicated is the syntax to write a message into the main window from a child thread, so this is simplified now. I have also made the "module" windows "kind of singletons" in the sense that the MainView keeps one instance of them all the time and the buttons just show or hide them. This way we no longer have to show them as blocking dialogs, so that you can have a window opened and still scroll through the log.
I have tested all the modules and they seem to be working correctly, although I have not tested all combinations of all parameters, so there might be some errors.