[mythtv-commits] Ticket #13517: Reducing memory usage by mythfilldatabase to 1/6 of original usage

[MythTV]

#13517: Reducing memory usage by mythfilldatabase to 1/6 of original usage
---------------------------------------+-------------------------------
 Reporter:  Hans Dingemans             |          Owner:  Peter Bennett
     Type:  Patch - Feature            |         Status:  assigned
 Priority:  minor                      |      Milestone:  needs_triage
Component:  MythTV - Mythfilldatabase  |        Version:  Master Head
 Severity:  medium                     |     Resolution:
 Keywords:                             |  Ticket locked:  0
---------------------------------------+-------------------------------

Comment (by Gary Buhrmaster):

 Replying to [comment:10 Hans Dingemans]:
 > Ehmm, I'm confused. That commit says: .....

 > What does that have to do with this situation?

 There is a history, and my previous comment covered the basics of the
 reasons (no reason to repeat that again), and I would encourage you to
 carefully review and understand the code and the email discussions on the
 -dev list and the implication(s).  However, most importantly it firmly
 reconfirmed and reinforced the precedent of "all or nothing" with explicit
 concurrence of the developers.  Flip-flopping on such decisions for each
 and every patch is not (well, has never been) the MythTV developers way.

 And of course the existing code would appear to do the appropriate thing,
 and (most importantly) the author seems to agree that the new code should
 do the appropriate thing.

 I have not seriously evaluated all the possible alternatives to know if
 fixing that may not require reading (streaming) the file twice (the first
 time just to validate the file), as the mythtv developers have also
 explicitly chosen to never use the transaction capabilities of mysql as
 you suggested as an alternative(1) (and for that matter to not use DB
 triggers or cascade deletes or blobs or ....), which results in different
 sets of code hoop jumping through out the code (including, possibly, this
 case).

 And while it may be appropriate to reconsider past decisions (especially
 those made decades ago), the forum for such developer discussions is not a
 patch ticket (it would be out of scope here).



 (1) Given the often huge set of changes in a larger lineup guide update
 (and the elapsed time to process the data), a single transaction might
 cause a different set of issues, and that is not even addressing that the
 table type would need to be changed (currently the mysql tables are
 explicitly forced to be myisam for a supported (by the project) DB, and
 myisam does not support database transactions), and that (myisam as the
 supported table), too, is an intentional design choice.

-- 
Ticket URL: <https://code.mythtv.org/trac/ticket/13517#comment:12>
MythTV <http://www.mythtv.org>
MythTV Media Center