- updated copyright notices
- added copyright notices that were missing
- changed python to python2
- added gpl-2/3 license texts
- removed THANKS.txt file as the wiki version is more up to date
- removed empty fpdb_db.py
- added GPL2 to debian license file
tested bulk import for PS and FTP, player stats and positional stats
also fixed a little bug that sqlite created HandsPlayers.actionString
with type REAL instead of VARCHAR
They were not yet available in (db.)hudchache.
Using the Bets and Call, together with stree(x)Agression the
aggression frequency and aggression factor can be calculated.
From Gerko on mailing list:
> I just did a trial. Use bulkimport for a single Pokerstars file
> switch setting and bulkimport a single Full tilt file.
> When screening the db all players in the database show the same siteId
> (2 for pokerstars)
> Or the other way if the first site was Full Tilt.
The Lambda function wasn't initialising the lambda function correctly.
This encoder is used to handle input from HH conversion, which needs to
end up as UTF-8 in the database. Switch the open-coded routine from
Database.py to this common routine so all encodings now take place in
the same file.
This encoder is used to handle input from HH conversion, which needs to
end up as UTF-8 in the database. Switch the open-coded routine from
Database.py to this common routine so all encodings now take place in
the same file.
The strings (names) as stored in database should always be UTF-8;
whatever the display locale is, we then need to convert from the storage
encoding to session encoding. When making database queries with players
names in them, the names must be reconverted to UTF-8.
The strings (names) as stored in database should always be UTF-8;
whatever the display locale is, we then need to convert from the storage
encoding to session encoding. When making database queries with players
names in them, the names must be reconverted to UTF-8.
The names should be always in UTF-8 encoding. At least for PostgreSQL
the encdoding of the database comes from the time of running 'initdb'
(which is different from 'createdb') and if the encoding was selected or
set to something else at that time, the following error will occur:
File ".../pyfpdb/Database.py", line 1630, in <lambda>
self.pcache = LambdaDict(lambda key:self.insertPlayer(key, siteid))
File ".../pyfpdb/Database.py", line 1661, in insertPlayer
c.execute (q, (site_id, _name))
File "/usr/lib/python2.5/encodings/iso8859_15.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u2122' in
position 10: character maps to <undefined>
This happens because 'name' is a regular string as opposed to a valid
unicode object. By forcing the string to unicode and encoding it in
UTF-8 the error goes away. In my case the database encoding was
ISO-8859-15 (latin9) but any other "wrong" encoding would trigger the
same problem.
This is a relatively common problem in python.
Was returning the player name instead of id in the case where the player exists in the database, but wasn't cached already
Removing some merge gunge too
fix call to storeHudCache in Database to use handStartTime rather than the undefined hand_start_time; stub out store_hands_players_stud_tourney as it looks like it was never updated to use current database setup. result: hud works, no longer crashes import, presumably does not store any hand info though.
HHC base guessMaxSeats returns existing value of maxseats if some prior code has set it somewhere already
Affected files:
* Configuration.py
* Database.py
* HandHistoryConverter.py
* fpdb_import.py
and setup.py to a lesser extent.
Logging requires a configuration file when initialising the class. If we
are executing from outside the source tree, this file is not present.
Catch config parser's error and try to provide the logging config file
from debian package path.
Update symlink target to match python-support from latest Debian and the
oncoming Ubuntu versions.
Cleaned up storeHandsPlayers and added storeHudCacheNew
Haven't decided on the data structures to be passed in as yet so the functions only insert the bare minimum and have a list of commented out variables
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.
