home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Database: Refactor MP1 database for multi seat usage
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Anthony Vaughan" data-source="post: 1286645" data-attributes="member: 153283"><p>You really can't overthink things, so far as I am concerned.</p><p></p><p>This is not about ego. It's about getting the best product out there. So, if you find issues let me know so I can address them.</p><p></p><p></p><p>All database writes are put into a queue - after the cache has been updated. The cache always has the latest data (for that session) and the database updates catch up. The updates run in a separate thread so they happen pretty quickly after the event. The queue handles updates coming from other users so the database IDs are always correct. Well, that's the intention anyway.</p><p>I get round the need to for the updates to return something by predetermining the ID - that's what Oracle does.</p><p>It's the other way 'round:</p><p> a) The cache is updated;</p><p> b) The database updates happen as and when the system allows.</p><p></p><p>There is a common misconception that connects are expensive. The first connection is expensive. All subsequent connections come from the internal database cache. Try it out and you'll see what I mean. All relational databases work this way. You gain far more by releasing resources as soon as possible and using them for as short a time as possible. In the case of MP, I do the first connection in the Init of the plugin programs. This way, when you close down MP you can close down the machine straight away. Try that with the current version and you will lose your latest updates.</p><p></p><p></p><p>That won't happen because LoadDirectory, in GUIVideoFiles, only processes an existing folder and my extra code only processes database records in that folder. It only works on one folder at a time as you navigate through MP (it doesn't loop through sub-directories).</p><p></p><p>There are two sides to this:</p><p> a) Manually deleting a video - the data for that video is also removed;</p><p> b) Navigating through existing folders using MP - MP now removes database records for files that no longer exist in the current folder. </p><p></p><p>This is sure to work because files are held by path and file name and MP only deletes records with a matching path and file name.</p><p></p><p>I have written another application that removes orphaned records and no-existent paths, on a daily basis.</p></blockquote><p></p>
[QUOTE="Anthony Vaughan, post: 1286645, member: 153283"] You really can't overthink things, so far as I am concerned. This is not about ego. It's about getting the best product out there. So, if you find issues let me know so I can address them. All database writes are put into a queue - after the cache has been updated. The cache always has the latest data (for that session) and the database updates catch up. The updates run in a separate thread so they happen pretty quickly after the event. The queue handles updates coming from other users so the database IDs are always correct. Well, that's the intention anyway. I get round the need to for the updates to return something by predetermining the ID - that's what Oracle does. It's the other way 'round: a) The cache is updated; b) The database updates happen as and when the system allows. There is a common misconception that connects are expensive. The first connection is expensive. All subsequent connections come from the internal database cache. Try it out and you'll see what I mean. All relational databases work this way. You gain far more by releasing resources as soon as possible and using them for as short a time as possible. In the case of MP, I do the first connection in the Init of the plugin programs. This way, when you close down MP you can close down the machine straight away. Try that with the current version and you will lose your latest updates. That won't happen because LoadDirectory, in GUIVideoFiles, only processes an existing folder and my extra code only processes database records in that folder. It only works on one folder at a time as you navigate through MP (it doesn't loop through sub-directories). There are two sides to this: a) Manually deleting a video - the data for that video is also removed; b) Navigating through existing folders using MP - MP now removes database records for files that no longer exist in the current folder. This is sure to work because files are held by path and file name and MP only deletes records with a matching path and file name. I have written another application that removes orphaned records and no-existent paths, on a daily basis. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Database: Refactor MP1 database for multi seat usage
Contact us
RSS
Top
Bottom