akumoth/peewee-issues huggingface dataset:
Issue: peewee tries to hard to connect to a data store
Author: dmead
State: closed
Created: 2015-07-22 18:38:15

I've just had a problem were i didn't have MySQLdb installed, so peewee failed over to sqlite3

this was really annoying because it happened silently and without warning.

im using a statement like this to connect

`db = MySQLDatabase('somedatabase', host='127.0.0.1', port=3306, user='user', passwd='pass')`


Where are you using sqlite3 been mentioned in your code example?
On Jul 22, 2015 11:08 PM, "Daniel Mead" notifications@github.com wrote:

> I've just had a problem were i didn't have MySQLdb installed, so peewee
> failed over to sqlite3
> 
> this was really annoying because it happened silently and without warning.
> 
> im using a statement like this to connect
> 
> db = MySQLDatabase('somedatabase', host='127.0.0.1', port=3306,
> user='user', passwd='pass')
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/coleifer/peewee/issues/667.


thats the point. i'm not. peewee is defaulting to write to a file called "peewee.db" every time.


Peewee will not do this silently. Can you share your model definitions? I'm wondering if you neglected to set the db for your models.


``` python
from myproject import database

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

i'm also using arnold to run table creation stuff, if that matters to you


Peewee raises an exception on not installing pymysql and MySQLdb! Which
version are you using?
On Jul 22, 2015 11:13 PM, "Daniel Mead" notifications@github.com wrote:

> thats the point. i'm not. peewee is defaulting to write to a file called
> "peewee.db" every time.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/coleifer/peewee/issues/667#issuecomment-123822485.


i have both installed. actually.


Pay attention, is your code running correctly? Any old edition of code
cached and run? Can you paste your file content and describe a little about
your process of run code?
On Jul 22, 2015 11:32 PM, "Daniel Mead" notifications@github.com wrote:

> i have both installed. actually.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/coleifer/peewee/issues/667#issuecomment-123828265.


Yeah, basically this doesn't add up. Peewee won't silently "fall back" to SQLite if you're trying to use MySQL. And if you don't have a mysql driver installed and try to use MySQLDatabase, it will raise an error.


my bad.

the ref i had inside the base model was bad. it was actually falling back to sqlite but it was my fault.
Issue: why does peewee default to it's own file?
Author: dmead
State: closed
Created: 2015-07-22 15:18:15

https://github.com/coleifer/peewee/blob/master/peewee.py#L3955

maybe i lack contact about sqlite? why is this hard coded to it's own filename?


That line of code is there to allow you to quickly create models that point to a SQLite database named `peewee.db`. So if you just imported `Model` and did not define your own database, it would use the `default_database`.

Most everyone will define their own db, though, so this is not an issue in practice, e.g.

``` python
from peewee import *

db = SqliteDatabase('my_database.db')

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

# application models extend `BaseModel`.
```
Issue: Inner query problem
Author: dneyirp
State: closed
Created: 2015-07-22 11:03:07

Hi. I need to execute the following SQL statement but use Peewee's library to do it and prefer not to use raw sql.
Table "Log" has has this structure:

``` sql
CREATE TABLE "Log" ("Id" INTEGER NOT NULL PRIMARY KEY, "DateTimeUTC" DATETIME NOT NULL,  "Value" INTEGER NOT NULL)
```

SQL query needing translation:

``` sql
select * from
    (select * from Log
     order by DateTimeUTC desc
     limit 20
    )
    order by DateTimeUTC
```

I have been helped by the author of Peewee ORM, Charles, with the following code:

``` python
inner_query = Log.select().order_by(Log.DateTimeUTC.desc()).limit(20)
query = Log.select().from_(inner_query).order_by(Log.DateTimeUTC)
```

This generates an error:
`OperationalError: no such column: t1.Id`

I was then given a modification to try:

``` python
inner_query = Log.select().order_by(Log.DateTimeUTC.desc()).limit(20)
inner_query = inner_query.alias('t1')
query = Log.select().from_(inner_query).order_by(Log.DateTimeUTC)
```

However I get another error:
`OperationalError: no such column: t1.DateTimeUTC`

Looking at the debug code Peewee provides:
`[2015-07-22 12:04:23,822] [peewee] DEBUG]: ('SELECT "t1"."Id", "t1"."DateTimeUTC", "t1"."Value" FROM (SELECT "t2"."Id" FROM "Log" AS t2 ORDER BY "t2"."DateTimeUTC" DESC LIMIT 20) AS t1 ORDER BY "t1"."DateTimeUTC" ASC', [])`
It seems that when Peewee is executing the first line of the last snippet `inner_query = Log.select()...`, the conversion to SQL is incorrect and only using the `".Id"` field instead of all fields in the select() and result in the "no such column" error. 

Firstly it seems that the need to add the line `inner_query = inner_query.alias('t1')` looks like a bug as "t1" is not used in my query.

Secondly there seems to be a bug somewhere in translating `select()` to SQL when you have an inner query as only one field is being used when all should be used.

Many thanks
P


Change:

``` python
inner_query = Log.select().order_by(Log.DateTimeUTC.desc()).limit(20)
```

To:

``` python
inner_query = Log.select(Log).order_by(Log.DateTimeUTC.desc()).limit(20)
```

If a subquery does not have an explicit selection, peewee assumes you just want the primary key, hence the missing column.
Issue: Property getters/setters don't work with `get_or_create`
Author: fluffy-critter
State: closed
Created: 2015-07-20 02:26:08

This is on version 2.6.3, as installed via OSX's `easy_install` function.

I have a project in which I'd like to automatically derive a human-readable sorting key from a title (or in this case, a band name). I have this code for it (simplified):

```
def to_key(name):
    return re.sub(r'^(a|the) (.*)$', r'\2, \1', name.lower())

class Band(BaseModel):
    @property
    def name(self):
        return self.display_name

    @name.setter
    def name(self, value):
        self.display_name = value
        self.sort_key = to_key(value)

    sort_key = CharField(unique=True)
    display_name = CharField(unique=True)
```

This works fine with the model constructor:

```
>>> band = Band(name='The stupidest band name ever')
>>> band.sort_key
'stupidest band name ever, the'
>>> band.display_name
'The stupidest band name ever'
>>> band.save()
1
```

but if I try to use it through `get_or_create` I get an error:

```
>>> band,created = Band.get_or_create(name="The Terrible Trio")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 4145, in get_or_create
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 2740, in get
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 2787, in execute
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 2470, in _execute
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 3199, in execute_sql
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 3048, in __exit__
  File "build/bdist.macosx-10.10-intel/egg/peewee.py", line 3191, in execute_sql
peewee.InterfaceError: Error binding parameter 0 - probably unsupported type.
```

although if I explicitly set the individual properties it's fine:

```
>>> band,created = Band.get_or_create(display_name="Harry",sort_key="Larry")
>>> created
True
>>> band.name
'Harry'
>>> band.display_name
'Harry'
>>> band.sort_key
'Larry'
```

Supporting this isn't a particularly big deal for this project, but it'd be a nice to have.

The obvious question would be how to support ambiguous things like:

```
Band.get_or_create(name="The Sugar Shock")
Band.get_or_create(name="Sugar Shock, The")
```

In this case I'd expect the first one to create a new entry with `display_name='The Sugar Shock'` and the second one to throw an exception because it'd try to create a new entry that violates the uniqueness constraint on `sort_key`, but I'm not sure if that's generally the correct thing to expect (or if this even makes a lick of sense in general).


Closing, because I realized that the underlying problem is with `get` and that trying to do a `get` on a derived key like this makes no dang sense.
Issue: Simple question on multiple Model instances from single Join query
Author: jessepeterson
State: closed
Created: 2015-07-18 21:15:02

First: thanks for Peewee: it's great! Sorry to litter the bug tracker with a simple question, but I'm not able to figure out how to get multiple model instances from a single joined row. For example:

``` python
q = Student.select(Student, Teacher).join(StudentTeacher).join(Teacher).where(Student.name == 'Bob')

for row in q:
    print row # is only a Student instance, where is Teacher?
```

When I iterate over `q` I only get a Student instance. How do I get the associated Teacher model instance out of a simple join query like above? When I turn on query logging it's clearly querying for the relevant fields.

I could use `.dict()` to get the raw values and rebuild each model instance separately I suppose but that seems overly laborious.


I should add that if I access the `related_name` references of my M:N table I can get to the associated data — but at the cost of multiple queries (hence the join is sort of useless). I _should_ be able to get two instances from a single query, no? `aggregate_rows()` and `prefetch()` don't seem to apply to this very simple case. Any help is appreciated!


You need to also select the junction table:

``` python
q = Student.select(Student, StudentTeacher, Teacher).join(StudentTeacher).join(Teacher).where(Student.name == 'Bob')
```

Then you can access it via:

``` python
row.studentteacher.teacher
```
Issue: Possible support for connection retry?
Author: josephschorr
State: closed
Created: 2015-07-13 10:26:20

We occasionally have servers failing to connect to the database due to sporadic networking issues with our service provider. Our service provider is currently investigating these issues, but until solved this leaves us having a few DB connections here and there fail.

I'm curious on thoughts about adding the ability to retry connecting to the database a specified number of times (probably 3 and with some form of backoff?), after which the exception would be bubbled up out of the call as it currently does. This would be user-configurable, perhaps on the `initialize` call of the `Proxy`.

Admittedly, not a great solution, but it would help in the short term and for software working in areas with less than stable networks.


Rather than adding this to Peewee itself, I'd suggest you write your own wrapper that does what you want:

``` python
from peewee import *
import time

db = PostgresqlDatabase('whatever')

def connect_db(retries=3, delay=5):
    while True:
        retries -= 1
        try:
            db.connect()
        except OperationalError:
            if retries == 0:
                raise
            time.sleep(delay)
        else:
            return True
```


Since we're using a `Proxy`, how would we override the `connect` call (or would we have to just make sure to call our own connect first everytime)?


Using the function from above, I imagine you would just write:

``` python
def connect_db(db, retries=3, delay=5):
    while True:
        retries -= 1
        try:
            db.connect()
        except OperationalError:
            if retries == 0:
                raise
            time.sleep(delay)
        else:
            return True

class ReconnectingProxy(Proxy):
    def connect(self):
        return connect_db(self.obj)

database = ReconnectingProxy()
database.initialize(some_other_db)
```
Issue: If custom primary_key is used, .save() with no PK doesn't work properly
Author: foxx
State: closed
Created: 2015-07-10 15:00:15

The following code does not raise any exceptions, but it doesn't save to the database either.

``` py
import peewee
import random

db = peewee.SqliteDatabase(':memory:')

class Message(peewee.Model):
    class Meta:
        database = db
    content = peewee.TextField()

class MessageCustomPrimaryKey(peewee.Model):
    class Meta:
        database = db
    id = peewee.TextField(default=1, primary_key=True, unique=True)
    content = peewee.TextField()

db.create_table(Message)
db.create_table(MessageCustomPrimaryKey)

# this works as expected
m = Message()
m.content = 'hello'
m.save()
assert m.id == 1
assert Message.select().count() == 1

# this does not
m = MessageCustomPrimaryKey()
m.content = 'hello'
m.save()
assert m.id == 1
assert MessageCustomPrimaryKey.select().count() == 1
```

Although creating objects in this pattern isn't very clean, it was a surprising result, because if the record was not saved to the backend then I would expect some sort of exception to be raised.

If I remove the custom `id` primary_key field, the problem goes away. I've trawled through the code and documentation, but cannot find anything to explain why this is happening.

Thoughts?


You need to save with `force_insert=True`.

http://docs.peewee-orm.com/en/latest/peewee/models.html#id3


I can't believe I missed that in the docs, my bad :( Thanks for the reply!


Fwiw, do you think it's worth patching so that an exception is raised if this situation is ever encountered? Although it's documented, it would be nice to have an exception raised in the event of human error maybe.


This definitely needs exception or some kind of logging, failing silently is not cool.

It *does* work, Peewee just assumes if the PK is present that it should do an update instead. Peewee is an active-record ORM. This is fundamental stuff.
Issue: Model with no primary key
Author: ballan91
State: closed
Created: 2015-07-09 22:45:25

It looks like while this is supported the documentation might be incorrect, I believe what the documentation actual intends is:

``` python
class MyData(BaseModel):
    timestamp = DateTimeField()
    value = IntegerField()

    class Meta:
        primary_key = None
```

While:

``` python
    primary_key = False
```

Seems to cause issues when trying to issue a .save() command.


Bug confirmed, curiously I just came across this issue myself and was about to report it, weird coincidence? Or perhaps a recent change?

Also, specifying `primary_key = None` doesn't actually disable the PK, as seen here;

``` py
class Audit(Model):
    class Meta:
        primary_key = False
    data = TextField()

>>> a = Audit(data="lol")
>>> a.save()
>>> a.id
1
```


Setting `primary_key = None` will cause peewee to auto-generate an `id` primary key field, so the docs are correct regarding `False`.

Unfortunately some APIs just don't work when you don't have any primary key at all, `save()` being one of them. You need to use the `.insert()` and `.update()` APIs instead.


Added some docs to that effect. 


Ah yeah, makes sense now, thanks for the quick reply!
Issue: Weird double exception while testing
Author: brendanWeb
State: closed
Created: 2015-07-09 03:57:17

I am getting both a sqlite3.IntegrityError as well as the peewee.IntegrityError that I am asserting for in my tests. Is this normal? It's causing my tests to error out.
Gist of the issue:
https://gist.github.com/brendanWeb/584d62ba5e7fb9c7338f


The problem is your call to `assertRaises`. It should be written:

``` python
self.assertRaises(IntegrityError, Post.create, description="hello world")
```

Or

``` python
self.assertRaises(IntegrityError, lambda: Post.create(description="hello world"))
```


Thanks!
Issue: Work in progress
Author: IxDay
State: closed
Created: 2015-07-07 16:36:01

Here is a first implementation just showing part of the code.

I have to fix the ability to iter through results
I also have an issue with the model class, If you have a better idea than creating a dedicated model class...

It breaks the tests but this is a work in progress ;)

linked to #647


Just before continuing do you think that I should continue implementing a custom Model class or you have a better idea on how to implement this?

I will also look at the implementation of the InsertQuery and avoid code duplication.


I'll take a look soon. One thing, you can probably just modify the existing `UpdateQuery` rather than putting this in `postgres_ext`. That's how I handled `INSERT...RETURNING` in the existing code.


I might try my hand at an implementation -- by doing so I'd like to explore some other ways of implementing this.


This is what I've come up with: https://github.com/coleifer/peewee/compare/HEAD...feature/update-returning


I noticed that you put all this code in the `postgresql_ext` module. My preference, since I imagine _some_ DBs besides postgres have this feature, is to use database feature flags to allow/disallow access to the `returning` APIs.

My thoughts on the implementation can be found here: https://github.com/coleifer/peewee/compare/HEAD...feature/update-returning


You know, looking around it seems like `DELETE` and `INSERT` both support `returning` as well. I think I'll update my patch to allow `returning` on delete and insert.


I've added support for `RETURNING` with `UPDATE`, `INSERT` and `DELETE` in my branch `feature/update-returning`:

https://github.com/coleifer/peewee/compare/HEAD...feature/update-returning

I think I'm going to go ahead and merge it today.


Just saw your patch (was on holidays), seems really cool, thanks for the quick implementation :)


Cool, thanks for sharing your code, really helpful!
Issue: Work in progress
Author: IxDay
State: closed
Created: 2015-07-07 16:30:57

Here is a first implementation just showing part of the code.

I have to fix the ability to **iter** through results
I also have an issue with the model class, If you have a better idea than creating a dedicated model class...

It breaks the tests but this is a work in progress ;)

linked to #647 


Wrong repository
Issue: Introducing returning for postgres
Author: IxDay
State: closed
Created: 2015-07-07 09:09:33

Hello, I am currently using peewee for managing a postgresql and I have started implementing a returning function on the update and select queries.

I am interested in contributing the results.

Here is an example:

``` python
user = User.update(active=False).where(User.registration_expired == True).returning()
```

The returning method will be a SelectQuery and support the selection arguments

``` python
sq = (User.update(active=False)
          .where(User.registration_expired == True)
          .returning(User.username))
for user in sq:
    print user.username
```

And also support the `tuples` and `dicts` chaining:

``` python
sq = (User.update(active=False)
          .where(User.registration_expired == True)
          .returning(User.username)
          .dicts())
for user in sq:
    print user.get('username')
```


Interesting, how is this implemented at the SQL level?


http://www.postgresql.org/docs/9.1/static/sql-update.html

`If the UPDATE command contains a RETURNING clause, the result will be similar to that of a SELECT statement containing the columns and values defined in the RETURNING list, computed over the row(s) updated by the command` (the last statement is false, every row can be accessed I tested it) .

The sql statement will look like this

``` sql
UPDATE users SET active = FALSE WHERE registration_expired = TRUE RETURNING username; 
```


Gotcha, cool! Can you share your code?


I will make a first pull request in order to see if the implementation looks good for you, with a simple test case.


I've gone ahead and merged support for `RETURNING` clauses on `UPDATE`, `INSERT` and `DELETE` queries. These only work with Postgresql, and are protected using a database config attribute, `returning_clause`. I will be adding documentation as well today, then I think it's good to go!
Issue: 2.6.2 install error
Author: pitchforks
State: closed
Created: 2015-07-07 00:11:41

I do setup.py install because I am packaging the source code tarball into a personal package for the Linux distribution that I'm using (it's Slackware64-14.1 with Python 2.7.5) and I'm getting this traceback for peewee-2.6.2:

```
Traceback (most recent call last):
  File "setup.py", line 14, in <module>
    ext_modules = cythonize('playhouse/speedups.pyx')
  File "/usr/lib64/python2.7/site-packages/Cython/Build/Dependencies.py", line 754, in cythonize
    aliases=aliases)
  File "/usr/lib64/python2.7/site-packages/Cython/Build/Dependencies.py", line 649, in create_extension_list
    for file in nonempty(extended_iglob(filepattern), "'%s' doesn't match any files" % filepattern):
  File "/usr/lib64/python2.7/site-packages/Cython/Build/Dependencies.py", line 103, in nonempty
    raise ValueError(error_msg)
ValueError: 'playhouse/speedups.pyx' doesn't match any files
```

It did not happen before, for 2.6.1 and earlier versions.

I have Cython-0.22 installed, but I'm pretty sure I installed that as dependency for something else, not for peewee.

I have also skimmed through the README and had a look at http://docs.peewee-orm.com/en/latest/peewee/installation.html, but could not find any useful hints.

What additional steps should I take for peewee-2.6.2 so setup.py build/install succeeds?

Thanks.


I just added that, maybe I needed to add it to `MANIFEST.in`... I pushed a new release, 2.6.3. Will you let me know if that fixes it?


2.6.3 builds fine, thank you.

The build also succeeded when I temporary uninstalled Cython. Since you did not modify the install instructions in the documentation, I assume that Cython did not become a mandatory build dependency for this new peewee version?


Cython is an optional dependency, but I had forgotten to include the cython module in the package data I believe. I can add info to the docs though, that's a good idea. Thanks for reporitng this!
Issue: Make filter work when there are multiple joins to the same table
Author: rammie
State: closed
Created: 2015-07-04 21:14:31


This is some pretty dense code... Can you summarize the changes? I'm not sure I'm going to merge it in yet, but some test-cases would also be helpful for my understanding of these changes.


Actually...man, this code is very difficult to parse in my head. Might be the 3 hours of sleep I'm running on, but since `filter()` is deprecated anyways I'm not too excited about adding this much complexity and then having to maintain it.


Let me take a stab at cleaning it up, and I'll add some tests as well. As I mentioned before, I like the way that the flask-peewee REST API processes the query string to generate a query, which relies on `filter()`. Maybe this could be moved to the playhouse instead?


On second thought, I decided to move this to the REST base classes itself API. Seems more logical if you're deprecating `filter()` anyway.