akumoth/peewee-issues huggingface dataset:
Issue: Get should throw exception if not unique
Author: keredson
State: closed
Created: 2016-06-03 17:13:24

again, behavior changing, so not for any point release, but hopefully some future incantation.
re: https://github.com/coleifer/peewee/issues/958


I've commented already that the semantics of get() are not going to change, so I will pass on this change.


3.0 man, 3.0!  :-)


It's not changing in 3.0 either man.
Issue: First limit 1
Author: keredson
State: closed
Created: 2016-06-03 14:49:42

for possible future inclusion (not 2.8.2) regarding https://github.com/coleifer/peewee/issues/959 or if anyone else wants to pull it into their forks.


I'd like to preserve the behavior where multiple calls to `first()` does not yield multiple queries. I _do_ agree, though, that there is benefit in applying a limit and that a second `peek()` method might more correctly. I've gone ahead and implemented this in a separate patch. You can compare notes to see how I've done this a bit differently: eeb6d4d727da8536906a00c490f94352465e90bb


+1
Issue: refactor _joins to use a defaultdict
Author: keredson
State: closed
Created: 2016-06-02 18:31:07


hah!  these unit tests are infuriating.  not sure how to reproduce this locally.  going to try some test commits...


How is this any better? I'm going to pass.


it's simpler and eliminates a class of bugs where one might forget to do the "if (does this key exist?) append else set" conditional check.
https://docs.python.org/2/library/collections.html#defaultdict-objects
Issue: Support MySQL 5.7 JSON data type
Author: ibushong
State: closed
Created: 2016-06-02 02:25:16

Is there plan to support the [JSON](https://dev.mysql.com/doc/refman/5.7/en/json.html) data type introduced in MySQL 5.7?


No plans on my part, but I would be willing to accept a patch that implemented it somewhat along the same lines as the `postgres_ext` or `sqlite_ext` playhouse modules.
Issue: Can not use PickledField with database proxy
Author: alexpantyukhin
State: closed
Created: 2016-06-01 18:39:00

The following code raise an error

``` python
from peewee import *
from playhouse.fields import *

database_proxy = Proxy()

db = SqliteDatabase('test.db')

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


class TestModel(BaseModel):
    data = PickledField()


database_proxy.initialize(db)

db.create_tables([TestModel])
```

the error:
`raise AttributeError('Cannot use uninitialized Proxy.')`


Fixed in b2d52ba7973e6d980ed9efae36322c16e9fec074 see #933
Issue: joining on two FKs to the same table doesn't work
Author: keredson
State: closed
Created: 2016-06-01 17:53:25

gens bad SQL:

``` python
import logging, os
import peewee as pw

logger = logging.getLogger('peewee')
logger.setLevel(logging.DEBUG)
logger.addHandler(logging.StreamHandler())

db_fn = 'example.db'
if os.path.exists(db_fn): os.remove(db_fn)
db = pw.SqliteDatabase(db_fn)

class Person(pw.Model):
  name = pw.CharField()
  class Meta:
    database = db

class Post(pw.Model):
  title = pw.CharField()
  author = pw.ForeignKeyField(db_column='author_id', rel_model=Person, to_field='id')
  editor = pw.ForeignKeyField(db_column='editor_id', rel_model=Person, to_field='id', related_name='edited_posts', null=True)
  class Meta:
    database = db

db.connect()
db.create_tables([Person, Post])

alice = Person.create(name='Alice')
bob = Person.create(name='Bob')
post = Post.create(title='My Post', author=alice, editor=bob)

for post in Post.select(Post).join(Person, on=Post.author).switch(Post).join(Person, on=Post.editor):
  print post #, post.author, post.editor
```

gens:

```
$ python test2.py 
[...]
('INSERT INTO "person" ("name") VALUES (?)', [u'Alice'])
('INSERT INTO "person" ("name") VALUES (?)', [u'Bob'])
('INSERT INTO "post" ("title", "author_id", "editor_id") VALUES (?, ?, ?)', [u'My Post', 1, 2])
('SELECT "t1"."id", "t1"."title", "t1"."author_id", "t1"."editor_id" FROM "post" AS t1 INNER JOIN "person" AS t2 ON ("t1"."author_id" = "t2"."id") INNER JOIN "person" AS t2 ON ("t1"."editor_id" = "t2"."id")', [])
```

notice the join conditions are right but the table aliases conflict.

i have a potential fix but i wanted an opinion if i'm using the API wrong somehow.

this is with the latest release:

```
$ git status
HEAD detached at 7670c9e
```


You need to use a model alias. See the [querying docs -- using model aliases](http://docs.peewee-orm.com/en/latest/peewee/querying.html?highlight=modelalias#using-model-aliases)

``` python
Author = Person.alias()
Editor = Person.alias()
query = (Post
         .select(Post, Author, Editor)
         .join(Author, on=(Post.author == Author.id))
         .switch(Post)
         .join(Editor, on=(Post.editor == Editor.id)))
```


ok, that second version works, but there is still a bug here.  an ORM api should not generate obviously invalid SQL.


> but there is still a bug here

In your opinion there is, in my opinion this is documented behavior. If you want to use a model and have it aliased to multiple aliases, you need to call `Model.alias()`.


```
Post.select(Post) \
   .join(Person, on=Post.author).switch(Post) \
   .join(Person, on=Post.editor)
```

gens non-nonsensical SQL.  how is non-nonsensical SQL not a bug?  there is no possible use case for having your lib generate duplicate table aliases.
Issue: make genned table aliases more human-friendly
Author: keredson
State: closed
Created: 2016-06-01 16:22:09

instead of: `select t1.id from ledger_entry as t1`
generate the alias from the table name: `select le1.id from ledger_entry as le1`

where the alias is an acronym of the table name.  makes it easier to read large joins w/ many tables.

@coleifer unit tests not updated yet.  i want to know if you're ok-with/opposed to this before i spend the time on that part.


I'm going to pass on this one as well. Seems like a special-case that really isn't that special. If you want to see an example of a custom query compiler, check out the tests -- there is one that will use the table name instead of `t{\d}`.


this is just totally bizarre to me.  why would you **prefer** meaningless table alias names?  what possible benefit is that?


If you're concerned about table aliases, you can always specify a default to use with a given model. Again, this is [documented](http://docs.peewee-orm.com/en/latest/peewee/models.html?highlight=table_alias#model-options-and-table-metadata).

``` python
class MyModel(Model):
    class Meta:
        table_alias = 'mm'
```

And @keredson tell your little buddies their emojis are really not helping anybody.


> this is just totally bizarre to me. why would you prefer meaningless table alias names? what possible benefit is that?

Can you please dial down your outrage? Can you dial down your tone? It's not helpful.


For posterity, this is not a bad idea in that using the table's name to create the alias will make the SQL more easy to scan. It was for the following reasons I decided not to merge this:

* Requires the addition of code to "fix" something that is technically not broken.
* The purpose of Peewee is to abstract away the process of writing SQL.
* You can explicitly set a model's table alias per-query or globally using existing APIs.
* The implementation is (subjectively) gross.
* Requires rewriting a huge number of test assertions.

Another misguided PR, not aligned with peewee's goals or aesthetic.
Issue: make genned SQL easier on the eyes by removing unnecessary quotes (ex…
Author: keredson
State: closed
Created: 2016-05-31 21:02:50

…: `select id from posts` instead of `select "id" from "posts"`)


Just noting for posterity, this is a horrible suggestion because it requires:

* The maintenance of a cross-vendor list of all SQL keywords to avoid invalid SQL (i.e. only quote names if they correspond to a SQL keyword)
* Inspecting each named entity to see if it contains spaces or other characters that would otherwise require quoting
* Requires re-writing hundreds of test assertions

All for ... fewer quotes in the SQL that this library is designed to abstract away. The idea is not a bad one in the sense that, yes, fewer quotes would make the sql more easy to read. But it is a bad one in the way it forces the implementation to become special-cased in numerous ways. Special cases are bad and are avoided as much as possible in peewee. It was for this latter reason, more than anything else, that this was closed without merge.
Issue: Perhaps DB connection URI retrieval in playhouse.flask_utils.FlaskDB can be deferred (init_app) until db_connect
Author: nad2000
State: closed
Created: 2016-05-26 12:05:43

I run into a configuration problem doing testing. FlaskDB ignores Flask configuration changes made in **setUp**, eg, `app.config["DATABASE"] = ...`. FlaskDB uses the "global" (original application configurations). I'd done testing **flask-sqlalchemy** and it has lazy DB connection initialization. Perhaps DB connection URI retrieval and connecton initialization in playhouse.flask_utils.FlaskDB can  be deferred (init_app) until db_connect.

A test for the "expected" behaviour in the context of a test would be:

``` python
#!/usr/bin/env python                                                     
# -*- coding: utf-8 -*-                                                   

import unittest                                                           
from flask import Flask                                                   
from playhouse.flask_utils import FlaskDB
import re               

app = Flask(__name__)                                                     
app.config["DATABASE"] = "sqlite:///app.db"  ## this URI shouldn't be used
db = FlaskDB(app)                                                         

class Atable(db.Model):                                                   
    pass                                                                  

@app.route('/')
def index():                                                              
    return "Configuration DATABASE: %s\n\nModel DATABASE: %s" \           
            % (app.config["DATABASE"], Atable._meta.database.database)    


class UserTest(unittest.TestCase):                                        

    def setUp(self):                                                      
        app.config["DATABASE"] = "sqlite:///test.db"                      
        self.app = app.test_client()                                      

    def test_app_db_settings(self):                                           
        rv = self.app.get('/')                                            
        assert "Model DATABASE: test.db" in str(rv.data)                  
        assert "Model DATABASE: app.db" not in str(rv.data)

       app_db_file, model_db_file = re.findall("\w*\.db", str(rv.data), re.M)          
       assert app_db_file == model_db_file

if __name__ == "__main__":                                                
    unittest.main()                                                       
```


Well, you can always just initialize your FlaskDB object by specifying `app=None`. Then when you're ready, you can call `init_app()` on it. That is the standard pattern for doing plugins and plugin factories with Flask.

For anything more than that you'll probably want to look at the following docs:
- [Run-time database configuration](http://docs.peewee-orm.com/en/latest/peewee/database.html#run-time-database-configuration)
- [Dynamically defining a database](http://docs.peewee-orm.com/en/latest/peewee/database.html#dynamically-defining-a-database)
Issue: fix the support of schema for PostgreSQL when we try to create a new table
Author: matrixise
State: closed
Created: 2016-05-23 19:27:22

In the Meta data of a class, we can specify the `schema` attribute, but this one is not used when we try to create the table. in fact the schema must be existing. in this case, we will create it after the creation of the table.

I prefer to propose a solution, I can rewrite it if necessary.


ok, my branch has some issues with travis, I will try to fix it asap
Issue: peewee.fn.Lower / Upper do not work correctly for some unicode characters
Author: anqxyr
State: closed
Created: 2016-05-22 17:31:13

Table Q looks like this:

| id | user |
| --- | --- |
| 1 | À |
| 2 | à |

And here is some code doing stuff to it.

``` python
In [1]: [i.id for i in Q.select().where(Q.user == 'À')]
Out[1]: [1]

In [2]: [i.id for i in Q.select().where(Q.user == 'à')]
Out[2]: [2]

In [3]: [i.id for i in Q.select().where(peewee.fn.Lower(Q.user) == 'À')]
Out[3]: [1]

In [4]: [i.id for i in Q.select().where(peewee.fn.Upper(Q.user) == 'à')]
Out[4]: [2]

In [5]: [i.id for i in Q.select().where(peewee.fn.Lower(Q.user) == 'à')]
Out[5]: [2]
```

Peewee version is 2.8.0.  SQLite version 3.7.9


You need to load the ICU extension, which can be compiled in automatically or built as a loadable extension.  Check the sqlite docs on the subject. This is a database-specific problem as opposed to a peewee issue.
Issue: "is_null" and  ">> None" operator  is parsed as "IS None" instead of  "IS NULL"
Author: iraklikhitarishvili
State: closed
Created: 2016-05-19 13:43:24

`column_name.is_null(True)` and `column_name >> None` expressions in `where` clause are returning `WHERE column_name IS None` in postgresql query.
i think just changing  [`db_value`](https://github.com/coleifer/peewee/blob/master/peewee.py#L928) to

``` python
  def db_value(self, value):
        """Convert the python value for storage in the database."""
        return 'NULL' if value is None else self.coerce(value)
```

will help
p.s i was using models translated from django


Since the value is parameterized, it will go in as the string 'NULL'.


thank you very mach. you are right. issue was that i tried to run it with `django_model.objects.raw(sql_query,params)` and django orm putted `None` from `params` as `None` instead of `NULL`.
Issue: Pass through field default values to SQL schema, or allow explicit creation of default values in model Meta class
Author: bcattle
State: closed
Created: 2016-05-18 20:41:17

Currently you can specify a model field's default value like 

```
new_users = peewee.IntegerField(default=0)
```

Currently this default is applied at the application level, in the [`add_field`](https://github.com/coleifer/peewee/blob/master/peewee.py#L4304) method of the ModelOptions class. 

It would be nice if this definition were passed through to the underlying SQL schema. So, when the table is created, a SQL statement of the form 

```
CREATE TABLE "stats" (
    "new_users" INTEGER NOT NULL DEFAULT 0, 
)
```

Is generated. This seems more consistent with how the `null=True` attribute produces SQL with the `NULL` attribute set appropriately. 

Since you can specify any Python callable for the `default=` value, either the calllable would be called once when the module is loaded, or you could use a syntax like the current `Check('price < 10000')` syntax to pass through a SQL string. This would allow you to use a sequence, etc. as a field default value. For example:

```
new_users = peewee.IntegerField(default=Default('nextval('user_no_seq')'))
```


Oh, I see you can already do this. From the [docs](http://docs.peewee-orm.com/en/latest/peewee/models.html#default-field-values): 

> The database can also provide the default value for a field. While peewee does not explicitly provide an API for setting a server-side default value, you can use the constraints parameter to specify the server default:
> 
> ```
> class Message(Model):
>     context = TextField()
>     timestamp = DateTimeField(constraints=[SQL('DEFAULT CURRENT_TIMESTAMP')])
> ```

Nice!


Yep! Thanks for checking the docs!
Issue: fix:playhouse connect database_url error
Author: jmpews
State: closed
Created: 2016-05-16 09:26:00

fix:playhouse connect database_url, the max_connections is mistaken for the type of 'str', so the error occur at https://github.com/coleifer/peewee/blob/master/playhouse/pool.py#L126

example:

```
BACKEND_MYSQL="mysql+pool://root:root@127.0.0.1/torweb?max_connections=20&stale_timeout=300"
```

`max_connections` and `stale_timeout` are mistaken for the type of 'str', and error occur

```
Traceback (most recent call last):
  File "/Users/jmpews/virtualenv/torweb/lib/python3.5/site-packages/tornado/web.py", line 1422, in _execute
    result = self.prepare()
  File "/Users/jmpews/Desktop/codesnippet/python/torweb/handlers/basehandlers/basehandler.py", line 18, in prepare
    db_mysql.connect()
  File "/Users/jmpews/virtualenv/torweb/lib/python3.5/site-packages/peewee.py", line 3402, in connect
    **self.connect_kwargs)
  File "/Users/jmpews/virtualenv/torweb/lib/python3.5/site-packages/playhouse/pool.py", line 126, in _connect
    len(self._in_use) >= self.max_connections):
TypeError: unorderable types: int() >= str()
```

and
perhaps there are still other types of errors
Issue: Cyclic ManyToManyField issues
Author: maciej-irl
State: closed
Created: 2016-05-13 18:34:08

Code below produces, instead of expected "1". Running Peewee 2.8.1. Same result when running HEAD.

```
Traceback (most recent call last):
  File "orm.py", line 26, in <module>
    DeferredAuthor.set_model(Software)
  File "/usr/local/lib/python3.5/site-packages/peewee.py", line 422, in set_model
    self.field.rel_model = rel_model
AttributeError: 'DeferredRelation' object has no attribute 'field'
```

ManyToManyField works great when just one object contains it. DeferredRelation seems to break it. If this is not a bug I would love some advice on making this work. Note I am not using `get_through_model` because in reality I'm using Postgres with all the tables in already place.

``` py
from peewee import *
from playhouse.fields import *

db = SqliteDatabase(':memory:')

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

DeferredContributor = DeferredThroughModel()
DeferredAuthor = DeferredRelation()

class Software(BaseModel):
    program = TextField()
    contributors = ManyToManyField(DeferredAuthor, through_model=DeferredContributor)

class Author(BaseModel):
    author = TextField(unique=True)
    software = ManyToManyField(Software, through_model=DeferredContributor)

class Contributor(BaseModel):
    contributor = ForeignKeyField(Author)
    software = ForeignKeyField(Software)

DeferredContributor.set_model(Contributor)
DeferredAuthor.set_model(Software)

db.create_tables([Contributor, Author, Software], safe=True)

Author.create(author='john')
Software.create(program='hello', author=1)
Contributor.create(contributor=1, software=1)
db.commit()

print(Software.get(Software.program=='hello').contributors.count())
```


It's actually not necessary to add a "backref" `ManyToManyField` as Peewee already does this. What you want is something like:

``` python
class Author(BaseModel):
    author = TextField(unique=True)

class Software(BaseModel):
    program = TextField()
    contributors = ManyToManyField(Author, through_model=DeferredContributor, related_name='software')
```

`Author.software` will now be a many-to-many field as well, without the need to re-define it.
Issue: Postgres syntax error while using db.execute_sql
Author: hkarasek
State: closed
Created: 2016-05-13 18:25:57

I have problem with the ' (single quote) in SQL query when passing arguments. I am doing something wrong or it's a bug? 
### Reproducer:

``` python
import peewee as pw

EVENTS_TABLE_PREFIX = 'events_'

db = pw.PostgresqlDatabase('events_api', user='test', password='passwd', host='localhost')
sql = 'CREATE TABLE %s (id SERIAL PRIMARY KEY);'

db.execute_sql(sql, ['test42'])
```
### Raises:

```
Traceback (most recent call last):
  File "/home/hkar/.virtualenvs/events_api/lib/python3.5/site-packages/peewee.py", line 3485, in execute_sql
    cursor.execute(sql, params or ())
psycopg2.ProgrammingError: syntax error at or near "'test42'"
LINE 1: CREATE TABLE 'test42' (id SERIAL PRIMARY KEY);
                     ^


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "peewee_bug.py", line 8, in <module>
    db.execute_sql(sql, ['test42'])
  File "/home/hkar/.virtualenvs/events_api/lib/python3.5/site-packages/peewee.py", line 3492, in execute_sql
    self.commit()
  File "/home/hkar/.virtualenvs/events_api/lib/python3.5/site-packages/peewee.py", line 3316, in __exit__
    reraise(new_type, new_type(*exc_args), traceback)
  File "/home/hkar/.virtualenvs/events_api/lib/python3.5/site-packages/peewee.py", line 127, in reraise
    raise value.with_traceback(tb)
  File "/home/hkar/.virtualenvs/events_api/lib/python3.5/site-packages/peewee.py", line 3485, in execute_sql
    cursor.execute(sql, params or ())
peewee.ProgrammingError: syntax error at or near "'test42'"
LINE 1: CREATE TABLE 'test42' (id SERIAL PRIMARY KEY);
```
### Environment

Ubuntu 16.04
python 3.5.1
python modules:

ecdsa==0.13
falcon==1.0.0
future==0.15.2
gunicorn==19.5.0
jsonschema==2.5.1
peewee==2.8.1
psycopg2==2.6.1
pycrypto==2.6.1
python-jose==0.6.1
python-mimeparse==1.5.2
simplejson==3.8.2
six==1.10.0


Where are the single-quotes coming from? I'm kinda confused.


There are a few weird things going on in the code you shared:
- Parameterizing the table name: typically you don't want to parameterize things like table names or other things that exist as part of the schema...it's more for external data.
- Postgres uses double-quotes for columns, tables, etc. Single quotes are used for string data.
- Any reason not to define a database model, or are you just using peewee for low-level database access?

To answer your question, though, you should just write:

``` python
sql = 'CREATE TABLE "test42" (id SERIAL PRIMARY KEY);'
db.execute_sql(sql)
```

If the table name is coming from an untrusted source (i.e. not hard-coded into your application) then this stackoverflow answer might be helpful:

http://stackoverflow.com/questions/13793399/passing-table-name-as-a-parameter-in-psycopg2