[mythtv] Ticket #3313: Add the ability for imdbpy to get the episode title format from the database

Hadley Rich hads at nice.net.nz
Mon Apr 16 06:33:14 UTC 2007

On Mon, 16 Apr 2007 11:44:18 you wrote:
>> Firstly, thinking about future expansion, does it make sense to use
>> separate classes for MythTV and MythVideo etc.? I think maybe it would be
>> does.
> You mean in the bindings? To me it might make sense,  depending what those
> class are meant to include.  However, maybe specific classes such as
> "MythDB" for
> connecting to the MythDB would make more sense.

I was thinking that the functions in find_meta.py deal only with mythvideo, so 
could be put in a MythVideo class. For example; instead of 

MythTV.getVideoMetadata and MythTV.setVideoMetadata we would have 
MythVideo.getMetadata and MythVideo.setMetadata

And eventually could have the same for MythMusic etc. I think that's a fairly 
logical separation.

The sample file I uploaded to the ticket had the main class as MythTV, I guess 
that could be better named as MythDB as it's a connection to the DB rather 
than MythTV itself. This would allow for a MythTV class to be added later to 
handle a connection to the backend etc.

>> Secondly, does anyone have an opinion on depending on sqlalchemy? It's not
>> a major concern for the moment given that there only a couple of functions
>> using SQL but I can see it becoming more and more convenient as the
>> mythtv.py file expands.
> SQLA is quite nice. It could be used if someone decides to expand the Python
> bindings, but for the current "bindings" which only fetch a setting from DB
> I see this as an overkill.

I do agree that it's overkill for the few functions at the moment.

I may go ahead and create a Sqlalchemy model for the myth database anyway when 
I have some time. Then it's done and can more easily be expanded on. It won't 
be difficult using the reflection functionality anyway, which should make it 
flexible of schema changes.



New Zealand's VoIP supplier

More information about the mythtv-dev mailing list