Conflicts:
pyfpdb/Database.py
Resolve by reverting to sqlcoder's version; it uses the nice insert in
fillDefaultData for each case now and having the DB backends separate
might be good for the foreseeable future.
Database.py : fillDefaultData()
Remove manual 'id' from INSERT command. In database schema,
TourneyTypes.id is a primary key and thus autoincrement. In postgres,
autoincrements are implemented as sequences - inserting a value
"manually" bypasses the sequence generation, which resulted in a
remarkably weird error.
Namely, upon the first hand to import, the insert fails due to primary
key violation. The default value from an unused sequence is 1, but a
row with such an id already exists.
The solution is to create the single row of default data values with
unspecified TourneyTypes.id, hence allowing postgres to generate the
correct id from the sequence. This way the import works again.
Database.py : fillDefaultData()
Sql-coder had fixed the default data insert, and in the process changed
the default type ID. Since his works in general case, I can remove my
modifications.
* Database.py : fillDefaultData()
PostgreSQL has a rather annoying (mis)feature when dealing with boolean
data types: raw 1/0 input as integer is not automatically cast to
boolean values. Instead, one must use one of several other ways of
signifying true/false.
http://www.postgresql.org/docs/8.4/static/datatype-boolean.html
documents the available and understood formatting.
Fix by special-casing PostgreSQL and making all boolean values fed as
strings, '1' for true and '0' for false.
PostgreSQL does not have an UNSIGNED specifier in its language.
Mysql's "TINYINT UNSIGNED" is postgreSQL's "SMALLINT" which is a bit
inconvenient but apart from annoying, not a problem.
Hud's noop() is called from gtk event handler, which passes
additional arguments. We don't care about them but we do want to prevent
HUD-error.txt from being flooded with TypeError messages.
* It seems that fpdb gets installed into /usr/share/python-support/
while many other packages end up in .../pyshared; fixed the symlink
target
* Fixed mail address in changelog, which now is the correct one
* Added postinst script to make fpdb.py executable again. This hack
is needed because dh_fixperms didn't allow to ignore the script's
permissions and the file is located in .../fpdb/ along with all the
other fpdb modules
* Told package manager to create /usr/bin/fpdb symlink pointing to
fpdb.py so we now have an application named "fpdb" in the system
When menu->reposition is called, only the HUD windows were moved to
their new positions. The auxiliary windows used for mucked cards
remained where they were at the time the HUD instance was created. This
caused mucked cards to appear in wrong places after the poker table was
moved.
Split positioning code in Mucked.py to its own method. Now the same
routine that moves HUD windows to their new places also invokes code
to reposition auxiliary windows.
Now the mucked cards are displayed at correct screen coordinates too.
It is not enough to use actual system locale in just one spot if all
the other encodings are hard-coded to latin1. Now that we have the real
locale available, do all string conversions [.encode($locale)] with
that.
Do we really need that annoying error note about table viewer not
working any longer? It's useless with postgres backend anyhow, so might
as well kill it off entirely.
Simplify error check, so that regardless of how the table name is
mangled, we now catch just the meaningful part.
When trying to obtain the lock, make sure that there is no transaction
block open (which tends to happen on error-paths); flush the database
connection before requesting exclusive lock.
The error message from postgres contains the said table as written in
original command. 'Players' != 'players', indeed. Now software can at
least start with postgres and an empty database.
If database backend is Postgres and the connection is over domain
socket, the only values in <database> node are:
* db_name
* db_server
* db_type
Now, for some reason the config reader unconditionally creates "tidy"
string representations for all possible keys. This means that
host, user and password are all empty strings (''), and not even
NoneType entities.
To catch the case for postgres, simply treat empty host the same as
undefined host.
Mika Bostrom