akumoth/peewee-issues huggingface dataset:
Issue: FlaskDB and Model with signal support
Author: ak4nv
State: closed
Created: 2016-08-12 08:41:28

Now `BaseModel` [class based on](https://github.com/coleifer/peewee/blob/master/playhouse/flask_utils.py#L153) peewee.Model without signals


Just subclass `FlaskDB` and override the `get_model` method to use the `Model` subclass from the `signals` extension:

``` python
from playhouse.signals import Model as SignalModel


class SignalsFlaskDB(FlaskDB):
    def get_model_class(self):
        if self.database is None:
            raise RuntimeError('Database must be initialized.')

        class BaseModel(SignalModel):
            class Meta:
                database = self.database

        return BaseModel
```

Voila!
Issue: peewee support multi process mode ? 
Author: rfyiamcool
State: closed
Created: 2016-08-11 02:49:34

peewee support multi process mode ?    How to create a connection dynamically?


Could you please be specific? What do you mean by "dynamically"? Honestly, please try to explain things so I can understand exactly what you're talking about, otherwise you are wasting both of our time.


Database connections are not shared across multiple Python interpreter processes. Peewee, by default, uses thread-locals to manage connection state, so database connections are not even shared across threads (though you can disable this). Using the standard APIs, there will typically be one connection open per thread. If you want to explicitly create a second connection, you can use the 

Here are some relevant sections of documentation based on my best guess as to what you were asking:
- http://docs.peewee-orm.com/en/latest/peewee/database.html#multi-threaded-applications
- http://docs.peewee-orm.com/en/latest/peewee/database.html#advanced-connection-management
- http://charlesleifer.com/blog/managing-database-connections-with-peewee/ (a blog post I wrote on connection management with peewee)

To quote from the second link:

> In some situations, however, you may want to manage your connections more explicitly. Since peewee stores the active connection in a threadlocal, this typically would mean that there could only ever be one connection open per thread. For most applications this is desirable, but if you would like to manually manage multiple connections you can create an ExecutionContext.
> 
> Execution contexts allow finer-grained control over managing multiple connections to the database. When an execution context is initialized (either as a context manager or as a decorated function), a separate connection will be used for the duration of the wrapped block. You can also choose whether to wrap the block in a transaction.

If none of this information helped answer your question, please comment with more information.
Issue: pwiz not output models.py  with Mysql BLOB
Author: rfyiamcool
State: closed
Created: 2016-08-10 05:19:54

pwiz not output models.py  with Mysql BLOB? 

parse error, My mysql filed is blob,  pwiz output TEXTFIELD .

Thanks U. 


The mapping in the `playhouse.reflection` module explicitly associates MySQL BLOB columns with `TextField`s. I wish I had left a comment as to why it is that way... There seems to be some odd behavior with the way MySQL / Python handle BLOBs compared to the other database engines Peewee supports out-of-the-box (the blob field test cases are skipped for MySQL). I've made a couple changes and will let the continuous integration run the tests and see what shakes out from there.


If you take a look here, it seems to be a limitation of the Python MySQL drivers:

https://github.com/django/django/blob/master/django/db/backends/mysql/introspection.py#L15-L37

Note how all the `BLOB` types get mapped to `TextField` -- this is also the behavior of pymysql:

https://github.com/PyMySQL/PyMySQL/blob/master/pymysql/constants/FIELD_TYPE.py

So rather than assuming BlobField everywhere, peewee does what Django does and assumes TextField. You can go back through the code and make replacements where needed, of course.
Issue: Issue with using percent sign
Author: bitnic028
State: closed
Created: 2016-08-09 12:28:49

A code like this

```
>>> from application.db.models import db
>>> query = 'SELECT 12 % 5;'
>>> res = db.execute_sql(query)
```

is crashing

```
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 3485, in execute_sql
    cursor.execute(sql, params or ())
IndexError: tuple index out of range
```

Certainly, in this case percent sign should replace by `mod()` function.


What database are you using?


Posgtrsql.


This is a quirk of `psycopg2`, which apparently treats "%" as placeholders. This StackOverflow question deals with the exact same issue:

http://stackoverflow.com/questions/14054920/psycopg2-indexerror-tuple-index-out-of-range-error-when-using-like-operat

To escape the percent sign, just use "%%":

``` python
In [5]: db.execute_sql('SELECT 12 %% 5;').fetchall()
Out[5]: [(2,)]
```
Issue: Retrieving data through a ManyToManyField fails with ForeignKeyFields as primary keys
Author: bfontaine
State: closed
Created: 2016-08-08 14:26:08

Here is a simple example:

``` python
from playhouse.sqlite_ext import SqliteExtDatabase
from playhouse.fields import ManyToManyField
from peewee import Model, ForeignKeyField

db = SqliteExtDatabase("yo.db")

class BaseModel(Model):
    class Meta:
        database = db

class A(BaseModel):
    pass

class B(BaseModel):
    pk = ForeignKeyField(A, primary_key=True)

class C(BaseModel):
    bs = ManyToManyField(B, related_name="cs")

# Call this method to reproduce the issue
def reproduce():
    db.create_tables([A, B, C, C.bs.get_through_model()], True)

    a = A.create()
    b = B.create(pk=a)

    print(list(b.cs))
```

Expected result: it should print an empty list

Actual result:

```
Traceback (most recent call last):
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 3485, in execute_sql
    cursor.execute(sql, params or ())
sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/x/app.py", line 29, in reproduce
    print(list(b.cs))
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 2967, in __iter__
    return iter(self.execute())
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 2960, in execute
    self._qr = ResultWrapper(model_class, self._execute(), query_meta)
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 2656, in _execute
    return self.database.execute_sql(sql, params, self.require_commit)
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 3492, in execute_sql
    self.commit()
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 3316, in __exit__
    reraise(new_type, new_type(*exc_args), traceback)
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 127, in reraise
    raise value.with_traceback(tb)
  File "/tmp/x/venv/lib/python3.4/site-packages/peewee.py", line 3485, in execute_sql
    cursor.execute(sql, params or ())
peewee.InterfaceError: Error binding parameter 0 - probably unsupported type.
```

Indeed, if we print `b.cs` we can see there’s a bad binding at the end:

```
<class 'app.C'> SELECT "t1"."id" FROM "c" AS t1 INNER JOIN "c_b_through" AS t2 ON ("t1"."id" = "t2"."c_id") INNER JOIN "b" AS t3 ON ("t2"."b_id" = "t3"."pk_id") WHERE ("t2"."b_id" = ?) [<app.A object at 0x7f2c13720d30>]
```

It should probably be using the foreign key directly instead of the model pointed _by_ it. I’m not really sure how to fix this in Peewee.


I reported this issue before the 2.8.2 release but I just tried and I can still reproduce it with the same code example and the latest release (2.8.2).


The issue has not been fixed, but I'm now looking into it.


Thanks for the code to repro - you have no idea how much I appreciate it!


Fixed


Thanks!
Issue: Query doesn't work using `&`
Author: Cee
State: closed
Created: 2016-08-08 09:58:16

``` python
tweets_today = (Tweet
                .select()
                .where(
                    (Tweet.created_date >= datetime.date.today()) &
                    (Tweet.is_published == True))
                .count())
```

I'm a python beginner and follow the [example](https://github.com/coleifer/peewee/blob/master/README.rst), but I couldn't get a correct answer when I use `&` mentioned above. However, when I replace `&` with `AND`, it works.


If I leave off the call to `.count()`, the SQL is:

``` sql
SELECT "t1"."id", "t1"."user_id", "t1"."message", "t1"."created_date", "t1"."is_published" 
FROM "tweet" AS t1 
WHERE (("t1"."created_date" >= ?) AND ("t1"."is_published" = ?))
```

The parameters passed into the query are `[datetime.date(2016, 8, 8), True]`.

I believe you are mistaken. And I have _no_ idea what you mean by "replacing it with AND" because "AND" is not valid Python. The `and` keyword is, but it does logical and (short-cutting), and cannot be overridden. Bitwise and `&` _can_ be overridden, and is required when writing queries with Peewee.
Issue: Pass kwargs from ensure_join to the join call.
Author: paulbooth
State: closed
Created: 2016-08-05 02:24:23

Allows join_type to be specified in ensure_join.

This will also allow any future arguments to join to automatically be handled through ensure_join.


Looks pretty good, just hesitating on pressing "Merge" because it slightly changes the API in a backwards-incompatible way. Then I thought "Oh, well, the method is not documented, so nobody's really using it." And _then_ I thought, "well, this guy's using it."

So, since I'm curious, what are you using this method for? It's a pretty obscure little helper function...

Secondly, what do you think about leaving `on=None` and just passing it along with the `**kwargs` to the `join()` method?


We needed something like this for our Customer model with a nullable foreign key to Address. When we pass in a customer query to filter according to our filter language that includes Address, we need to make sure that Address has been joined without doing unnecessary switch and joins. So, we want to ensure_join on Address, but it is nullable and we want to JOIN_LEFT_OUTER, which we can't currently do.

Interestingly, we can actually get around this using the non-private method get_query_meta and inspecting the join_dict, but this is a bit of hack:

```
_select_fields, join_dict = customers.get_query_meta()
    for join in join_dict[Customer]:
        if join.dest is Address:
            break
    else:
        customers = customers.switch(Customer).join(Address, JOIN.LEFT_OUTER)
```

re: keeping on=None: Great idea, keep backwards-compatibility and future-proofing against any new join kwargs, sounds like a winner to me. Future code spelunkers might wonder why `on` is provided separately from other kwargs, but this should be obvious to allow for positional invocations. Change inbound


Awesome, thanks for this patch!
Issue: New release, please.
Author: kdart
State: closed
Created: 2016-08-05 00:11:23

Hello. First of all, thanks for the great ORM. I'm using it in my project.  My project defines some custom fields. Now if I use the current distribution from pypi I get an exception thrown and my project basically crashes. But I see the fix for it is already in master. If I install from master everything works fine. It would be really nice, though, if my users could just get it off of pypi like the other packages. It's been like this for quite some time, so I thought I'd ping you to please do a point release to simplify our installation. Thanks!


Definitely, can you tell me what commit in particular you're referring to?


The error is this:

```
Traceback (most recent call last):
  File "/opt/Cellar/python3/3.5.2_1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/opt/Cellar/python3/3.5.2_1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Volumes/USER/Users/keith_dart/src/costest/costest/db/models.py", line 88, in <module>
    class EquipmentModel(BaseModel):
  File "/opt/lib/python3.5/site-packages/peewee.py", line 4479, in __new__
    field.add_to_class(cls, name)
  File "/opt/lib/python3.5/site-packages/peewee.py", line 1081, in add_to_class
    self._constructor = model_class._meta.database.get_binary_type()
  File "/opt/lib/python3.5/site-packages/peewee.py", line 407, in __getattr__
    raise AttributeError('Cannot use uninitialized Proxy.')
AttributeError: Cannot use uninitialized Proxy.
```

Because I'm also using the proxy object.

This fix is in b2d52ba7


2.8.2 is pushed to PyPI.


a33e8ccbd5b1e49f0a781d38d40eb5e8f344eee5
Issue: Add support for PostgreSQL geometric types
Author: guidoiaquinti
State: closed
Created: 2016-08-02 13:46:17

I'm opening this issue (as suggested in the [docs](http://docs.peewee-orm.com/en/latest/peewee/playhouse.html#postgresql-extensions)) to keep track of PostgreSQL [geometric type](https://www.postgresql.org/docs/current/static/datatype-geometric.html) support


See an example of custom field for that here https://github.com/BaseAdresseNationale/ban/blob/master/ban/db/fields.py#L33


While I personally have no intentions of implementing fields for those data-types, I would merge a pull-request that added support in the `playhouse.postgres_ext` module. On a personal note, I stopped using Postgres about 2 years ago and I haven't looked back, so new features to the `postgres_ext` extension are going to need to have either 1) strong interest from the community, 2) patches submitted by an ambitious contributor, or 3) a feeling that the presence of a particular feature will be important to users in evaluating whether or not to use Peewee. This last one was the case for both `jsonb` and `tsvector` (full-text search). Geometry fields just don't have the same panache, I guess :) .

I'm going to close this for now, but if you have any additional thoughts on the matter please leave a comment. Thanks!
Issue: Explicitly check database for None in ModelOptions
Author: joeyespo
State: closed
Created: 2016-08-01 05:50:10

I was trying to use Werkzeug's [`LocalProxy`](http://werkzeug.pocoo.org/docs/0.11/local/) with the [Context Usage approach described in the Flask docs](http://flask.pocoo.org/docs/0.11/appcontext/#context-usage):

``` python
import peewee
from werkzeug.local import LocalProxy


@LocalProxy
def db():
    _db = getattr(g, '_db', None)
    if _db is None:
        _db = g._db = db_url.connect(current_app.config['DATABASE_URL'])
    return _db


class BaseModel(peewee.Model):
    class Meta:
        database = db


class MyModel(BaseModel):
    ...

def init_app(app):
    @app.teardown_appcontext
    def teardown_db(exception):
        _db = getattr(g, '_db', None)
        if _db and not _db.is_closed():
            _db.close()
        g._db = None
```

The above fails because `bool(db)` [returns `False`](https://github.com/pallets/werkzeug/blob/0.11.10/werkzeug/local.py#L322-L326) on unbound proxies, which causes Peewee [to use its `peewee.db` default database](https://github.com/coleifer/peewee/blob/2.8.1/peewee.py#L4263).

This fixes the problem without changing other existing behavior.


Ahh, surprised this one's managed to stay undiscovered until now. Thanks for the patch!
Issue: SqliteMigrator: fix edge case in rename_column
Author: jberkel
State: closed
Created: 2016-07-31 14:45:15

When renaming a column with the same name as the table
the table name will get accidentally replaced in the “CREATE index”
query:

``` sql
CREATE INDEX
 "table_name_first_column_second_column" ON   
 "table_name" ("first_column", "second_column")
```


Actually there are still some cases where this might fail. Maybe there's a better way to recreate the indexes?


Fixed in 5aa587c
Issue: PostgresqlDatabase class does not have `_upsert` statement
Author: cheetah90
State: closed
Created: 2016-07-26 19:10:11

Looking at the [PostgresqlDatabase class](https://github.com/coleifer/peewee/blob/b84ca0c8bc724b8cccd0b5bbd557abc04885c478/peewee.py#L3945), it does not specify the statement for `_upsert`, so when [`query._upsert` is called here](https://github.com/coleifer/peewee/blob/b84ca0c8bc724b8cccd0b5bbd557abc04885c478/peewee.py#L1982) , it just return `None`.


Follow-up, Postgresql has implemented `UPSERT` in version > 9.5. [See here](https://wiki.postgresql.org/wiki/UPSERT)


@cheetah90 -- there are two issues currently open tracking this exact thing:
- #942 
- #853
Issue: pwiz columns invalid names
Author: CosmicAnalogue465
State: closed
Created: 2016-07-21 07:47:04

in mysql fields can be named:
"source id"
"marketing/position"
in this case pwiz creates python model attributes of the same name.
Related issue:  https://github.com/coleifer/peewee/issues/184


Hmmm....


Can you explain this in a bit more detail? What exactly is the nature of this bug?


This is a example of generated code from pwiz

class Flag(BaseModel):
    description = TextField(null=True)
    flag id = CharField(null=True)
    name = CharField(null=True)

python will syntax error:

```
flag id = CharField(null=True)
      ^
```

SyntaxError: invalid syntax


Solution could be to escape the fields name and use a db_column property

flag_id = CharField(db_column='flag id', null=True)
Issue: pwiz returns no such option -1 
Author: yanchao7511461
State: closed
Created: 2016-07-19 23:31:01

```
C:\Users\mypc>python -m pwiz -e mysql -H localhost -p3306 -uroot -Proot wpdb > wpmodel.py

Usage: pwiz.py [options] database_name

pwiz.py: error: no such option: -1
```

these texts is from my pc. 

When I use pwiz on my vps , it returns 'no such option: -c ' 


How strange...couple questions:
1. Is your VPS running linux?
2. Are you using the exact same invocation on your VPS, or something different?
3. How did you install Peewee on your computer?
4. How did you install Peewee on your VPS?
5. What version of peewee?

Note: I edited your comment to add code formatting around the console output.


I'm able to run the following without issue, for what it's worth:

```
$ python -m pwiz -esqlite somedb.db
```


Try the following locally:

```
python -m pwiz -e mysql -u root -P root wpdb > models.py
```

I'm not sure how shell redirection works on windows, but I'm assuming the same semantics as bash.


Have you had a chance to look at this?


Closing due to inactivity, my guess is this was user error.
Issue: Implement alternative DeferredRelation semantics
Author: c0ldcalamari
State: closed
Created: 2016-07-19 21:36:08

The [semantics behind circular foreign key dependencies](http://docs.peewee-orm.com/en/latest/peewee/models.html#circular-foreign-key-dependencies) get kind of unwieldy when you have more than a few models (and they're spread over multiple files).  This is because the `DeferredRelation` object has to be defined, used, then the other model defined in another file, then `set_model` has to be called on the original, and then you're left with the object reference dangling around that has no purpose.  IE the example in the docs:

``` python
# Create a reference object to stand in for our as-yet-undefined Tweet model.
DeferredTweet = DeferredRelation()

class User(Model):
    username = CharField()
    # Tweet has not been defined yet so use the deferred reference.
    favorite_tweet = ForeignKeyField(DeferredTweet, null=True)

class Tweet(Model):
    message = TextField()
    user = ForeignKeyField(User, related_name='tweets')

# Now that Tweet is defined, we can initialize the reference.
DeferredTweet.set_model(Tweet)
```

It would be better if it all happened in the model definition with an optional parameter given to `DeferredRelation`.  Like:

``` python
class User(Model):
    username = CharField()
    # Tweet has not been defined yet so use the deferred reference.
    favorite_tweet = ForeignKeyField(DeferredRelation('Tweet'), null=True)

class Tweet(Model):
    message = TextField()
    user = ForeignKeyField(User, related_name='tweets')
```

This would remove the need for the extra variable in the global namespace and the coordination of it over multiple files.  And since the parameter is optional, it can be fully backwards-compatible with the old syntax.

Thank you!


That's a very nice API. Depending on the class name (a string) is something I try to shy away from, as errors can occur despite the code appearing to be perfectly valid, for instance a typo or you happen to change the model name in one place and not the other.

I like the API, though, and agree that it would be worth supporting if done in a backwards-compatible way. Thanks for the patch, looking at it now.


Awesome. Thanks, I've merged your patch, really appreciate you taking the time to fix this one and implement such a clean patch.
Issue: Issues with counting uuid in Postgresql
Author: bitnic028
State: closed
Created: 2016-07-19 07:29:52

Issues with counting uuid, with other type fields the problem is avoid.

For example:

```
import peewee
from uuid import UUID

class User():
    id = UUIDField(primary_key=True)
    login = CharField()
    department = ForeignKeyField(Department, related_name=u"users_in_department", null=True)

class Department():
    id = UUIDField(primary_key=True)
    name = CharField()
```

Then:

```
d = (Department.select(
    Department.name,
    fn.COUNT(User.id).alias('total_users')
    ).join(User).group_by(Department.name))
for t in d:
    pass

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2047, in next
    obj = self.qrw.iterate()
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2107, in iterate
    return self.process_row(row)
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2185, in process_row
    setattr(instance, column, func(row[i]))
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 1105, in python_value
    return None if value is None else uuid.UUID(value)
  File "/usr/lib/python2.7/uuid.py", line 133, in __init__
    hex = hex.replace('urn:', '').replace('uuid:', '')
```

But `User.login` instead `User.id`

```
d = (Department.select(
    Department.name,
    fn.COUNT(User.login).alias('total_users')
    ).join(User).group_by(Department.name))
for t in d:
    pass
```

works correctly/


Thanks for including the traceback. Looks like the exception itself got cut off. Could you please include that? Will make debugging a bit easier... I'm just guessing here, but is psycopg2 already providing a uuid and peewee is treating it like it's a string?


All code with all traceback:

```
>>> from application.db.models import Department, User
>>> from application.db.models import db
>>> from peewee import fn
>>> k = Department.select(Department.prefix, fn.COUNT(User.id).alias('total_users')).join(User).group_by(Department.prefix).dicts()
>>> for t in k:
...     print t
... 
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2047, in next
    obj = self.qrw.iterate()
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2107, in iterate
    return self.process_row(row)
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2196, in process_row
    res[column] = func(row[i])
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 1105, in python_value
    return None if value is None else uuid.UUID(value)
  File "/usr/lib/python2.7/uuid.py", line 133, in __init__
    hex = hex.replace('urn:', '').replace('uuid:', '')
AttributeError: 'long' object has no attribute 'replace'
```


Oh of course! Sorry, yes. For now you can work around this by calling:

``` python
fn.COUNT(User.id).coerce(False).alias('total_users')
```

But I am working up a patch to fix this.


Fixed in b84ca0c8bc724b8cccd0b5bbd557abc04885c478