akumoth/peewee-issues huggingface dataset:
Issue: Foreign Key "ID descriptor" name incorrect when using `db_column`
Author: ibushong
State: closed
Created: 2017-06-29 22:40:05

```python
class Event(BaseModel):
    venue = ForeignKeyField(Venue, db_column='place_id')

...

Event.select().where(Event.venue == 5)  # this works fine
Event.select().where(Event.venue_id == 5)  # --> AttributeError: type object 'Event' has no attribute 'venue_id'
Event.select().where(Event.place_id == 5)  # --> This is successful, though, IMO, the above expression should be the correct one.
```

Hmm actually I guess I could see this being "correct". But just wanted to make sure it was expected.

I definitely understand your confusion, and likely the docs aren't clear on this point.

Inside `ForeignKeyField.add_to_class()` you can see that the "id descriptor" gets its attribute from the db_column (if set) and otherwise will be the field's name + "_id":

```python
        self.db_column = obj_id_name = self.db_column or '%s_id' % self.name
        if obj_id_name == self.name:
            obj_id_name += '_id'
```

So what you're seeing is correct according to the above logic.

Yeah, I eventually found that. I guess I just felt that if you're "renaming" a foreign key field, then both the name-descriptor and id-descriptor values would change accordingly. My goal in the example was to entirely replace the usage of place/place_id with venue/venue_id (without having to rename the actual database column). When I'm thinking about the venue FK, I want to hide/abstract-away the fact that under the hood it's actually referencing the `place_id` column.


I don't want to break backwards compatibility in case anyone was relying on the behavior described in your issue, *however* I've added a new parameter to `ForeignKeyField` that allows you to specify the name of the "object id descriptor". Your declaration would read:

```python
venue = ForeignKeyField(Venue, db_column='place_id', object_id_name='venue_id')
```

Awesome. That's a good solution. Thanks!
Issue: can not use ArrayField when I imort PostgresqlExtDatabase?
Author: wdrich
State: closed
Created: 2017-06-26 16:40:40

when I import PostgresqlExtDatabase like this:
 from playhouse.postgres_ext import PostgresqlExtDatabase

that say:"NameError: name 'ArrayField' is not defined"


thanks

Um...are you referencing `ArrayField` somewhere in your module? `ArrayField` is defined in `playhouse.postgres_ext` so to use it you'll need to import it along with `PostgresqlExtDatabase`.

after that, I import ArrayField with:
from playhouse.postgres_ext import ArrayField

that say:"peewee.ProgrammingError: hstore type not found in the database. please install it from your 'contrib/hstore.sql' file"

thanks


other wise:
I did not use 'hstore'

That is ok， NOW！！

i forgot add hstore extension
use ‘ create extension hstore’
Issue: Idea: Table prefixing
Author: tomvlk
State: closed
Created: 2017-06-25 15:38:01

Hello there,
First of all thanks for the simple and yet so powerful ORM!
I got one of our users that is asking if I can provide database table prefix configuration for my application. The application I'm talking about is PyPlanet, (issue from the user: https://github.com/PyPlanet/PyPlanet/issues/378).

I can most probably fix this myself with some kind of hacky method that will override the table name generation, but instead it would be cool to have this feature in Peewee itself where you can give the option to prefix all the tables with a prefix given in a configuration. (Also, I don't really want to hack this deep in Peewee).

I'm curious how you think about the idea.

To customize the table name on a one-off basis, you set the `db_table` option on the model's inner `Meta` class.

To set the table name dynamically, you can actually specify a different `Meta` attribute `db_table_func`. This should be a callable that receives the newly-created `Model` class, and returns a string to use as the table name.

I think this should probably accomplish what you want.
Issue: utf8 stored inside BlobField errors
Author: maugch
State: closed
Created: 2017-06-25 14:06:25

I have a database TEXT field stored as utf8mb4 on mysql which is translated to 
`description = BlobField(db_column='description', null=True)`
I tried to use the model and store data interactively without any problem. When I use the model in my program, I get :
```
Traceback (most recent call last):
  File "getSqlliteData.py", line 91, in <module>
    main()
  File "getSqlliteData.py", line 73, in main
    getStuffFromJson(item,id_recipe)
  File "/home/me/wp/python/database.py", line 244, in getRecipeFromJson
    recipe.save()
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 4971, in save
    rows = self.update(**field_dict).where(self._pk_expr()).execute()
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 3303, in execute
    return self.database.rows_affected(self._execute())
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 2820, in _execute
    return self.database.execute_sql(sql, params, self.require_commit)
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 3677, in execute_sql
    self.commit()
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 3501, in __exit__
    reraise(new_type, new_type(*exc_args), traceback)
  File "/usr/local/lib/python2.7/dist-packages/peewee.py", line 3670, in execute_sql
    cursor.execute(sql, params or ())
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 226, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorvalue
peewee.OperationalError: (1366, "Incorrect string value: '\\xA0  \\x0A  ...' for column 'description' at row 1")
```
The error comes when I try to update a row on the DB. Note that it does happen even if I do a get() and then a save(), which means I get my utf8 string from the database and then try to put it back on it with 0 changes (I should avoid that, but I'm still learning).

I think there is a problem on how data are stored on my Model, possibly a bug in peewee?
In order to avoid it, before i save() my object, I added the following two lines:

```python
if myitem.description is not None:
        myitem.description = u' '.join(myitem.description).encode('utf-8').strip()
```
I'm not sure how to write a simple test case. Is this description enough?

I'm not quite following...if you're just looking to store text (encoded as UTF-8), the proper field to use is the `TextField`.

Can you try modifying your code to use `TextField` instead of `BlobField` and see if that resolves the issue?

Yes TextField works indeed. I think pwiz generated it as BlobField. I thought it was right since it can be huge. I am not sure now if the behaviour when it's BlobField is correct though.


Glad it's working.
Issue: flask note-taking app FTSModel classes must use the default `docid` primary key.'
Author: quah6o
State: closed
Created: 2017-06-19 14:07:17

Hello together,

I'm new to python and only have a few basic programming skills.
I found this tutorial which creates a [flask note-taking app](http://charlesleifer.com/blog/saturday-morning-hacks-adding-full-text-search-to-the-flask-note-taking-app/). It is seperated in three steps. The first two steps work without any problems.
The complete project can be downloaded in [this gist](https://gist.github.com/coleifer/d93d6c43e59698d149c0).

But when I run the third step now, the following happens:

    (.p2) qua@mbp:0:~/python/flask-note-v3$ python main.py
    Traceback (most recent call last):
      File "main.py", line 5, in <module>
        from models import FTSNote
      File "/Users/qua/python/flask-note-v3/models.py", line 125, in <module>
        class FTSNote(FTSModel):
      File "/Users/qua/.p2/lib/python2.7/site-packages/peewee.py", line 4855, in __new__
        cls.validate_model()
      File "/Users/qua/.p2/lib/python2.7/site-packages/playhouse/sqlite_ext.py", line 281, in validate_model
        'FTSModel classes must use the default `docid` primary key.')
    peewee.ImproperlyConfigured: FTSModel classes must use the default `docid` primary key.
    (.p2) qua@mbp:1:~/python/flask-note-v3$ python app.py
    (.p2) qua@mbp:0:~/python/flask-note-v3$

I try to get this project working and modify it to suit my needs. By that I hope learning a bit more of python.

Can you help me? (I already asked this on /r/learnprogramming/)

Regards,
Qua

Ahh yeah, the code is probably a bit out-dated and does not reflect what I've since learned about some best practices for the full-text search extension. Let me see about updating things.

Ahh shit, I see I already left a note on code compatibility at the top of the post. I'm going to leave this alone for now, as I don't have time to go back through the code to update it all. Apologies for leaving you hanging -- I'll try to post an update, and when I do I'll update this ticket.

Ah I should read more carefully. I will use a older version for now. Thanks!
Issue: pwiz fails with cross-schema foreign keys
Author: albireox
State: closed
Created: 2017-06-19 02:30:21

Not sure if there is a solution for this, but I'm trying to run pwiz on a schema that as foreign keys referencing other schema in the same DB. pwiz fails with

```
Traceback (most recent call last):
  File "/Users/albireo/.pyenv/versions/3.6.1/bin/pwiz.py", line 201, in <module>
    print_models(introspector, tables, preserve_order=options.preserve_order)
  File "/Users/albireo/.pyenv/versions/3.6.1/bin/pwiz.py", line 47, in print_models
    database = introspector.introspect(table_names=tables)
  File "/Users/albireo/.pyenv/versions/3.6.1/Python.framework/Versions/3.6/lib/python3.6/site-packages/playhouse/reflection.py", line 520, in introspect
    src = columns[foreign_key.table][foreign_key.column]
KeyError: 'platedb_plate_pk'
```

where `platedb_plate_pk` is one of the columns that are a foreign key to a column on a different schema.

Sorry, no plans to support that.

Is this supported now?
Issue: Checking record exist
Author: kadnan
State: closed
Created: 2017-06-15 23:56:58

I know about exception thrown in this regard, just want to know whether there's some `count` or `exists()` method to check whether some record returned or not?

ffs man documentation

* http://docs.peewee-orm.com/en/latest/peewee/api.html#SelectQuery.exists
* http://docs.peewee-orm.com/en/latest/peewee/api.html#SelectQuery.count

I was searching for the same thing (I don't usually RTFM right away either). Just to let you know that your links don't take you to the right place on the page as I assume the # is supposed to do.

* http://docs.peewee-orm.com/en/latest/peewee/api.html#SelectBase.exists
* http://docs.peewee-orm.com/en/latest/peewee/api.html#SelectBase.count

tl/dr

```python

query = User.select().where(User.username == 'reads-the-manual')
if query.exists():
    print('there are %s users who %s' (query.count(), 'read the manual'))
```

Funny thing is that I had to google something similar after 4 years and I found my own opened issue 😆 

Hell yeah. I've had that happen once or twice myself.
Issue:  get() raising exception
Author: rrzaripov
State: closed
Created: 2017-06-15 09:39:37

This is my code:

```python
# -*- coding: utf-8 -*-
from peewee import *
from playhouse.sqlite_ext import SqliteExtDatabase

__database_file__ = 'test.db'
database = SqliteExtDatabase(__database_file__)


class TestModelDB(Model):
    class Meta:
        database = database


class TestDB(TestModelDB):
    k = TextField(null=False, unique=True)
    v = TextField(null=False)


database.connect()
database.create_tables([TestDB])

tdb = TestDB()
with database.transaction():
    tdb.create(k='key1', v='value1')
tdb.get(tdb.k == 'key1')

```

This give next traceback witn python 2.7 and last peewee release:

```
Traceback (most recent call last):
  File "C:/git/get_peewee.py", line 25, in <module>
    tdb.get(tdb.k == 'key1')
  File "C:\Python27\lib\site-packages\peewee.py", line 4926, in get
    return sq.get()
  File "C:\Python27\lib\site-packages\peewee.py", line 3179, in get
    clone = self.paginate(1, 1)
  File "C:\Python27\lib\site-packages\peewee.py", line 397, in inner
    clone = self.clone()  # Assumes object implements `clone`.
  File "C:\Python27\lib\site-packages\peewee.py", line 2771, in clone
    return self._clone_attributes(query)
  File "C:\Python27\lib\site-packages\peewee.py", line 3008, in _clone_attributes
    query = super(SelectQuery, self)._clone_attributes(query)
  File "C:\Python27\lib\site-packages\peewee.py", line 2775, in _clone_attributes
    query._where = self._where.clone()
AttributeError: 'bool' object has no attribute 'clone'
```

get() shortcut is broken? Or maybe I'm doing something wrong? 


You're working with an instance but the `get()` method is a class-method. So:

```python
with database.transaction():
    TestDB.create(k='key1', v='value1')
tdb = TestDB.get(TestDB.k == 'key1')
```
Issue: Inspecting query column names
Author: josePhoenix
State: closed
Created: 2017-06-12 17:29:07

I have some code that spits out an HTML table from some query results:

```python
    <table>
      <tr>{% for column in columns %}<th>{{ column }}</th>{% endfor %}<th>
    {% for result in results %}
      <tr>{% for column in columns %}<td>{{ result[column] }}</td>{% endfor %}</tr>
    {% endfor %}
    </table>
```

The best way I've found so far to get the `columns` from the query is:

```
results = query.execute()
first_row = results.next()
columns = first_row._meta.sorted_field_names
```

Is there a better way? (Incidentally, it's surprising to me that `list(results)` acts the same whether or not I call `results.next()`...)

This type of question is more appropriate to stackoverflow.

However...when you create a query, you necessarily know what columns are being selected. So how can there be a problem?

Because you may want to write your code in such a way that it can be reused without passing the names of columns explicitly, especially because this information is already part of the results object.

It appears that you get a different API depending on whether speedups are enabled. With speedups disabled, there is a `column_meta` attribute on peewee.NaiveQueryResultWrapper that exposes all the metadata.

```
>>> type(results)
<class 'peewee.NaiveQueryResultWrapper'>
>>> for f in results.column_meta: print(f.name)
obsid
pi_last_name
obs_date
exptime
```

> Because you may want to write your code in such a way that it can be reused without passing the names of columns explicitly, especially because this information is already part of the results object.

I definitely get that...especially in a template, like your example.

I've updated the speedups module to expose the column_meta attribute, see f11802807f5e05dddeb32f93b8c84703b49bb498
Issue: #1287 - Support ManyToManyField in model_to_dict
Author: gcscaglia
State: closed
Created: 2017-06-01 17:16:29

Adds `dereference_many_to_many_fields` parameter to `model_to_dict` function.

This parameter controls whether to hide the junction table for `ManyToManyFields`.
See the related issue for details.

The default value is False, which preserves the old behavior for compatibility.

I've also added some simple tests for the new behavior; Let me know if they are insufficient and/or something should be changed.

I've merged a patch that adds support manytomany in model_to_dict. Available in Peewee 3.x.

http://docs.peewee-orm.com/en/latest/peewee/playhouse.html#model_to_dict
Issue: model_to_dict - Support ManyToManyField
Author: gcscaglia
State: closed
Created: 2017-05-31 21:19:20

Consider the following models:

```python
class Tag(Model):
    name = TextField(unique=True)

class Gallery(BaseModel):
    title = TextField(null=True)
    tags = ManyToManyField(Tag, related_name='galleries')
```

When calling `model_to_dict` in a `Gallery` instance, one would expect the result dict to be:

```python
{
    'id': 1,
    'title': 'my title',
    'tags': [
        {
            'id': 1,
            'name': 'my tag'
        }
    ]
}
```

But the actual result is:

```python
{
    'id': 1,
    'title': 'my title',
    'gallerytagthrough_set': [
        {
            'id': 1,
            'tag': {
                'id': 1,
                'name': 'my tag',
            },
        },
    ],
}
```

While I do realize this is the result from how `ManyToManyField` works under the hood, the whole point of `ManyToManyField` is to pretend there is no relation table at all. Should't the returned dict be like the first one?

+1 for this

This is fixed in 3.0a by 0914cee. Example from test-case:

```python
class Owner(TestModel):
    name = TextField()

class Label(TestModel):
    label = TextField()

class Gallery(TestModel):
    name = TextField()
    labels = ManyToManyField(Label, backref='galleries')
    owner = ForeignKeyField(Owner, backref='galleries')

GalleryLabel = Gallery.labels.through_model

    def test_manytomany_field(self):
        data = (
            ('charlie', 'family', ('nuggie', 'bearbe')),
            ('charlie', 'pets', ('huey', 'zaizee', 'beanie')),
            ('peewee', 'misc', ('nuggie', 'huey')))
        for owner_name, gallery, labels in data:
            owner, _ = Owner.get_or_create(name=owner_name)
            gallery = Gallery.create(name=gallery, owner=owner)
            label_objects = [Label.get_or_create(label=l)[0] for l in labels]
            gallery.labels.add(label_objects)

        query = (Gallery
                 .select(Gallery, Owner)
                 .join(Owner)
                 .switch(Gallery)
                 .join(GalleryLabel)
                 .join(Label)
                 .where(Label.label == 'nuggie')
                 .order_by(Gallery.id))
        rows = [model_to_dict(gallery, backrefs=True, manytomany=True)
                for gallery in query]
        self.assertEqual(rows, [
            {
                'id': 1,
                'name': 'family',
                'owner': {'id': 1, 'name': 'charlie'},
                'labels': [{'id': 1, 'label': 'nuggie'},
                           {'id': 2, 'label': 'bearbe'}],
            },
            {
                'id': 3,
                'name': 'misc',
                'owner': {'id': 2, 'name': 'peewee'},
                'labels': [{'id': 1, 'label': 'nuggie'},
                           {'id': 3, 'label': 'huey'}],
            }])
```
Issue: attrdict causing issues with doctests
Author: kennethlove
State: closed
Created: 2017-05-30 21:04:02

Using the suggested method of `from peewee import *` brings in `JOIN` and friends, which are all instances of `attrdict`.

If you want to write and run doctests in your code, then, running `python -m doctest your_script.py` will throw a `KeyError` as it attempts to look up the `__wrapped__` attribute as `doctest` checks to see if it's a wrapped function. Example follows:

```python
File "C:\Users\Kenne\.virtualenvs\nicecore\lib\site-packages\peewee.py", line 318, in __getattr__
  return self[attr]
KeyError: '__wrapped__'
```

Seems like the solution would be to add a `try/except` block to the `attrdict` class.
Issue: Very strange error with data update (MySQL)
Author: MarcSky
State: closed
Created: 2017-05-30 08:35:21

Good afternoon, I encountered a very strange mistake. I need to add bonuses to my users every day. To do this, I get a list of users who have the opportunity to receive a bonus and in the cycle update their bonus fields in the database. I do it atomically. And it happens, so some fields are updated from one user and others are not, for example, gaming money for some increases and others do not, and in the database it is written that a person received a bonus. Very strange, one user object, some data is updated, the other is not. I used to use Sqlite before and everything worked fine until I had a lot of users.

Please can u help me, i dont undastand where is mistake :(( Why one field in row changed but other not.


    PEOPLE_PER_PAGE = 100
    all_count_users = User.select(fn.Count(User.id)).where((User.balance > 0.0) & (User.daily_profit == False)).scalar()
    pages = math.ceil(all_count_users / PEOPLE_PER_PAGE)
    for i in range(0, pages):
        users = User.select().where((User.balance > 0.0) & (User.daily_profit == False)).paginate(i + 1, PEOPLE_PER_PAGE)
        for user in users:
            with database.atomic():
                current_percentage = percentage
                if user.referral_individual != None and user.referral_individual > 0:
                    current_percentage = user.referral_individual
                profit = round(formula(user.balance, current_percentage), 2)
                user.residue = round(user.residue + profit, 2)
                user.total_profit = round(user.total_profit + profit, 2)
                user.daily_profit = True
                user.save()

All the daily_profit field is updated perfectly, but not all the residue field changes. I just do not eat anything like that at all! Operation is atomic.

I'm not sure, if you could put this into a failing test-case that demonstrated a bug in Peewee then I would be happy to look into it. As it is, this type of question is more appropriate for stackoverflow or the peewee mailing list. http://docs.peewee-orm.com/en/latest/peewee/contributing.html#questions
Issue: Facilitate case insensitive searches
Author: Naatan
State: closed
Created: 2017-05-25 18:44:59

The docs state:

> LIKE and ILIKE with SQLite
> Because SQLite’s LIKE operation is case-insensitive by default, peewee will use the SQLite GLOB operation for case-sensitive searches. The glob operation uses asterisks for wildcards as opposed to the usual percent-sign. If you are using SQLite and want case-sensitive partial string matching, remember to use asterisks for the wildcard.

Unfortunately it does not touch on the not at all unlikely scenario of wanting to do case insensitive LIKE queries. It would be nice if peewee touched in its docs, ideally facilitating it, otherwise just stating that you should use `SQL()`.

For case-insensitive LIKE you would just use ILIKE.

You should make that clearer in the docs, this currently isn't evident.

ILIKE is called ILIKE because it's case-insensitive.

I get that now, but that's not self-evident. And it's not something you can search the docs for because nowhere does it say the word "insensitive".
Issue: HStoreField from playhouse.postgres_ext
Author: bmlis
State: closed
Created: 2017-05-24 09:20:02

`HStoryField.db_field` value seems to be incorrect. When creating model with HStoreField and trying to migrate it I get:
```
peewee.ProgrammingError: type "hash" does not exist
```
even though the hstore extension is installed. When I changed db_field to `'hstore'` value migration was applied without any problems.

My bad, I was using wrong db connection
Issue: CompositeKey primary key not inheritable
Author: rhkubiak
State: closed
Created: 2017-05-22 05:24:23

I have a model A in which the primary key is defined via CompositeKey. Model B inherits from model A. A database table generated from B does not have a primary key. 
The things get better if the 'elif' in the code below (peewee version 2.10.1) is replaced with just an 'if':

        composite_key = False
        if model_pk is None:
            if parent_pk:
                model_pk, pk_name = parent_pk, parent_pk.name
            else:
                model_pk, pk_name = PrimaryKeyField(primary_key=True), 'id'
        elif isinstance(model_pk, CompositeKey):
            pk_name = '_composite_key'
            composite_key = True

What do you think?

Thanks for reporting this. I've pushed your suggested fix along with a test-case.