[mythtv] Request: MythHelp

[usleepless at gmail.com]

Stuart,

On 2/7/07, Stuart Morgan <stuart at tase.co.uk> wrote:
> On Wednesday 7 February 2007 10:17, usleepless at gmail.com wrote:
> >  - i removed all silly query.size() calls, as per the qt-docs
>
> Removing the query.isActive() calls in favour of query.size() may have been
> more appropriate in cases where "query.size() > 0" is used.
>
> query.isActive does not indicate that the query returned any results, only
> that it was executed successfully. If query.size > 0 is used then that
> suggested the original author wanted to check that the query returned a
> result.

i suggest that you read up on the code, on qsqlquery and try to find a
proper argument why all those size() & isActive() calls are there in
the first place, while in 95-99% of the cases a call to query.next()
would suffice and is needed anyway. what's wrong with

q.exec();
if/while(q.next())
{
// work
}

?

actually, i remember exactly one case where the size of the resultset
really needed to be established. in that particular case i just added
a counter to the while(query.next()) loop, since the queried before
the loop, but actually only uased after the loop. i think it was in
the guide code.

> So yes, using both is redundant (although a very minor issue) and a patch
> for this probably would be accepted. Have you ever submitted such a patch?

they might be both redundant. what is your opinion?

and why would i go about patching HEAD if postgresql-support is
"out-of-the-question" ? why would i supply a patch
optimizing/normalizing the schedulerquery on a branch i will never run
because postgresql-support is "out-of-the-question" ?

> If anyone has been hostile on the subject of mutli-db support, then it's
> probably because people won't take "no" as an answer. It's been established
> that we won't support multiple databases, the increased burden of
> maintaining
> that support is just one reason that immediately comes to mind.

this is just plain bullshit. excuse my language. what is the increased
burden of writing iso92/99-sql? what is the burden of removing those
silly calls? you don't need to abandon the mysql-functions( TODAY etc
), there is a compatibility-function-pack  for those in
postgresql/contrib.

actually, mysql is a burden upon mythtv development. just read up on
the latest plan to create a workerthread for updating the filesize.
hilarious!

in the process of porting mythtv-0.20 to freebsd, i encountered a
panic in the pvr500-driver. upon reboot mysql complained about a
broken table, i ran the repair command and it flushed the table (
capturecard ). just one panic, and immediatly the database is
corrupted. that won't happen with postgresql, and it was just a
reminder for me: ah, yes, this is why i abandonded mysql behind 5
years ago! it is still a piece of crap!

> It also
> ignores other fundamental programs with the current system. The preferred
> solution is to use an embedded database, probably embedded mysql.

fundamental programs? problems i assume?

it is you _perceiving this as a problem because you are unable to
listen to arguments and get back on a previous decision. i don't see
any problem with using qsqlquery with the db-drivers qt comes with (
mysql, postgresql, mssql, *sql ).

> You seem to have taken rejection on the postgreSQL issue very personally and
> so you now spend your time being destructive instead of constructive. Ideas
> and patches are rejected all the time, even my own, most people accept that
> and move on, why can't you?

don't you see i have moved on? i am happy with my own
mythtv-0.18-postgresql, and am contributing to the freebsd port of
0.20. i just will never run it myself, since the port doesn't address
the mysql issue. and i have no need for 0.20.

but it would be nice to be able to install a stock-mythtv and pointing
it to my postgresql-server. ofcourse. but it just ain't so.

> N.B. Patches against anything other than HEAD won't be accepted before you
> start submitting patches against a two year old version. We have better
> things to do than adapt those changes to the current code base.

like creating worker threads for disfunctional db systems. good luck!

i am willing to patch a whole lot of files if consensus is reached
about multi-db compatibility ( which is a qt feature )

regards,

usleep