SQLiteDatabase Plugin for MP2 (2 Viewers)

[Lehmden]

Hi.
I'm testing V0.6. ATM it don't look as if deleted media is removed from DB. But I did not do a complete rebuild of DB up to now. So maybe this is the reason for that. I will come back here as soon as I have more to report.

BTW, can we expect a lot of database changes for Alpha3? I'm asking if I can import more stuff without a need to do this again soon...
Now I have extra folders for MP2 on which I place Hardlinks to the Movies/Series I recently want to watch and not the "real" collection at "real" places... Some day I want/need to change this but I don't want to do the import of my complete collection too often.

 

[Lehmden]

Hi.
Want to give feedback on this after removing and reimporting my 2000+ episodes test- collection. The import itself seems to be a little bit slower, but that wasn't measured, just a guess.. I haven't explicitly tested to delete some files after importing jet but the wrongly imported files were removed after a reimport added them to DB correctly.
As my Filesystem Structure ("Fringe/1/S01E01 - Flug 627.mkv") isn't supported by MP2 I got "series" named "2" or "7" or so every now and then also all files are MKV with proper Metatags. Up to V0.5 this wrongly scrapped files stayed inside DB when they finally are scrapped correct so I had them twice in DB. This is not the case with V0.6 Here the wrong items are removed. I will do some tests with adding and deleting files directly later but I think this will work also.

 

[Lehmden]

Hi.
To finish this, I now can confirm that no longer existing files are removed from DB properly.

 

[MJGraf]

Thanks a lot for testing!

 

[MJGraf]

I'm planning to add the source code of this plugin to a feature branch in our git repo when I find the time, to make it easier for others to contribute. But I have three questions (maybe directed at @morpheus_xx and / or @chefkoch):

• In what directory shall I put this database plugin? \Incubator or \Source\Backend\Database ? I think this plugin is not "rtm" until we have solved the EntityFramework CodeFirst problem with TVE 3.5 so the incubator would be the natural choice. On the other hand, we also have ScimoreDB and FirebirdDatabase in \Source\Backend\Database which AFAIK are anything but "rtm". Besides that having it in \Source\Backend\Database would mean that we don't have to move it around when it is rtm and as long as we keep it in a separate branch, it doesn't hurt. I'm fine with everything, so please advise...
• In the separate branch, shall I deactivate the MSSQLCE plugin and activate this plugin in the solution settings? Since the branch deals with this plugin it would certainly make sense to do so because you are unlikely to use the MSSQLCE plugin when you compile this branch. On the other hand when we later merge this into dev, we would have to undo these changes (at least until we make this the standard database, but this will take a while and a lot more testing...). Is there a best practice?
• My plan is to keep this plugin always updated to the latest dev branch. My conclusion from many threads about git usage is that at least when pushing to dev (which I will not do), I should do a local fetch/rebase before. What about such a feature branch? Shall I regularly do a local fetch/rebase and push it to this feature branch to keep it updated to the current dev branch? On the other hand my understanding is that this deletes part of the branch history - so other who have pulled the feature branch before may have problems. Please advise...

Sorry for the potentially stupid questions, but I'm trying to get used to Git and how we use it for MP2.
Thanks,
Michael

 

[morpheus_xx]

All those questions are valid and important.

The "incubator" folder was created to have a place for new plugins to be developed until they are "ready". But now we already have a lot of plugins there which can be seen "ready", but we have not yet decided when we should move them. I suppose to move the "finished" ones after Alpha 3 is out. We should also move the not supported DB backends to incubator.
With your backend you should start in incubator as well.

You should enable the SQLite plugin/disable MSSQLCE plugin in a separate commit, so we can merge it separately from the code changes.

Longer running development branches I also rebase regulary to match with dev branch, so I would say this approach is ok.

 

[chefkoch]

We should also move the not supported DB backends to incubator.
With your backend you should start in incubator as well.

I am not sure if moving plugin folders around as soon as they are not maintain anymore is a good idea. Maybe it might be good enough to add Readme files to their directories? In general the folder location is Backends\Database is not wrong.

Besides adding a readme, we also could consider removing the dll files for these projects from the repository, because

• I expect these plugin are broken and
• if somebody continues to work on them, I expect him also to update the binaries to latest versions

but we won't allow committing any binaries anymore.

So in case the binaries are removed we also can add a note about filename & version it to the readme.

 

[chefkoch]

Regarding the SQLite plugin, I would like to suggest the following:

• commit the code (either to Incubator or Backend\Database > morpheus can decide this) within it's own branch: SQLiteDatabase
  
• create a second branch (or within your own fork...) where this plugin is enabled and the MSSQLDatabase is disabled: SQLite_ENABLED

The SQLite_ENABLED might contain only one commit for disabling and enabling the two DB plugins.
This way you can rebase one commit as much as you want, without the need to rebase a lot of commits from the actual SQLite plugin and it's fixes etc. over and over. So the history of SQLiteDabase branch won't be broken.

This way the SQLiteDatabase plugin also can be merged to dev earlier than it is rock-solid stable & tested, because it is not enabled and won't actually effect the products' stability.

 

[MJGraf]

Hi Tommy,

that's interesting - thanks! But maybe I didn't understand the rebase part, yet, sorry...
I creat the SQLite branch based on dev and push the SQLite code as it is now (SQLite disabled, SQLCE enabled).
Then I create a second branch SQLite_ENABLED based on the SQLite branch and just push one commit to the SQLite_ENABLED branch where I enable SQLite and disable SQLCE.

Now what I'm using for development for future fixes is apparently a local copy of SQLite_ENABLED. But when I get your suggestion right, the fix shouldn't be pushed to the remote SQLite_Enabled, but to the remote SQLite?!?

If so, I understand that I only have to rebase the one commit in SQLite_ENABLED to the latest commit of SQLite to keep it up to date. But to my understanding this doesn't help if I want to keep SQLite (and SQLite_ENABLED) up to date with DEV. I would have to rebase SQLite to the latest DEV from time to time to keep it up to date. But then I have probably broken SQLite_ENABLED because SQLite's history was rewritten?!? And I can't rebase SQLite_ENABLED to DEV because the code of the SQLitePlugin is neither contained in DEV nor in SQLite_ENABLED (the original source push was only to SQLite).

Maybe I'm getting this completely wrong - as mentioned, I'm a newby to Git...

Thanks for your help!
Michael

 

[Lehmden]

Hi.
What's about TVE 3.5 and SQLite? I know there is some work going on this, but I don't know how far this went. If this is solved properly I think we could swap to SQLite as default (replacing SQLCE) as SQLite has no size limit and is faster a lot...
I'm using SQLite on daily base and did not encounter any issues (excerpt of TVE 3.5) so far...