[mythtv-users] Deleting recordings after conversion

[Gary Buhrmaster]

On Sat, Oct 19, 2013 at 1:07 PM, Thomas Boehm
<mythtv-users at lists.boehmi.net> wrote:
> Michael T. Dean wrote:
...
>> Much better than using bash + echo + mysql  + direct DB editing (which
>> can result in corrupt data in your DB) would be to use a simple Python
>> script to delete the recording.  That way, in the event (or when, I
>> should say) the database schema changes, your user job will continue to
>> work and you won't break anything.
>
> To a non-(python)programmer that script looks by far more complicated
> than that simple bash one liner.
>
> And are you saying that in the future the table "recorded" or the
> columns "recgroup" or "autoexpire" could be named differently? And what
> guaranties that the python script keeps working in that case?

The only guaranties in life are death and taxes.  However, what I
think Michael is saying (and I am sure he will correct me), is that
the database schema will change, and since the entire business
logic is in the code (that means referential integrity and consistency)
directly editing any table runs a very high risk of "screwing something
up" that cannot be fixed.  Now, if you spend enough time to review
all the MythTV code, and commit to checking each (new) commit
to see if your knowledge of the database and the business logic
is still correct, you might be able to directly update the database
in such a way that you do not break things(*).  But suggesting that
approach to others without their doing the same thing (reading every
commit from now until the future) puts them at risk (usually without
them understanding that risk.  To put it another way, if you
manually directly update the database, you have voided the
warrantee.  The python and perl bindings have a sort of "promise"
that any manipulation performed by them will also implement any
business logic required to insure the database is still consistent.

btw, while I have no idea if it makes it for 0.28, as I understant
it there have been plans/desires (but lack of time) to reorganize
some of the recorded tables for quite some time.  Regardless,
things will change, because the devs and the users want
improvements, and some of those improvements will require
schema changes.

Gary

(*) Full disclosure.  I *have* spent that time (and continue to
watch all commits) and *have* directly updated the database.
I fully understand that my database is no longer "supported",
and would never ask for any assistance for any future
strangeness.