akumoth/peewee-issues huggingface dataset:
Issue: Primary keys that aren't integers
Author: matthewturk
State: closed
Created: 2011-09-05 00:09:21

We're currently using the (hex/char) representation of UUIDs for a database, to use as primary keys.  It looks like the current implementation requires Primary Key (and thus the .save() method) be an integer, and this is further checked through the isinstance call during creation of a model.  It would be really great if we could use a TextField, or any field, as primary key.


Well, it really just looks like it's searching for a pk that evaluates to a nonzero...it will be tricky since the postgresql adapter checks the value of a sequence for the last insert id.  Otherwise its just that bit in the BaseModel that checks for a PrimaryKeyField.

On the other hand, a non-integer primary key can be more expensive to query on and join on... might be worthwhile to implement instead the ability to add unique indexes and have something along the lines of the workaround suggested here:
http://stackoverflow.com/questions/3936182/using-a-uuid-as-a-primary-key-in-django-models-generic-relations-impact/3944247#3944247


Interesting point, and one I didn't know about.  I'll take a look into it -- thank you!


I've added ability to specify a unique keyword arg when creating fields:
https://github.com/coleifer/peewee/commit/c3460e32ae375984c97f28c6ec8f7b65a8ead8cf


This is awesome -- thank you very much!


Glad that commit helps -- I'm actually gonna leave this one open for now as I agree it _should_ be possible to use a TextField or something else for a primary key.


+1 , in some case it would be important, agree it should be possible to use a CharField


+1 to a primarykey CharField


Also relevant: biginteger fields


Started working on this in a branch: feature/non-integer-pk -- there are some interesting ramifications:
- primary keys may not be autoincrementing which affects default save() and create() behavior
- primary keys won't necessarily have a sequence so postgresql will need to have different last_insert_id behavior if so
- foreign keys need to match the column type of the primary key


Alright!  I think I have gotten this working.  It can be seen in the field refactor branch:

https://github.com/coleifer/peewee/tree/feature/field-refactor

For a diff:

https://github.com/coleifer/peewee/compare/feature/field-refactor

Tests are passing in sqlite and postgresql.  Saving models is a little bit different when using a non-integer autoincrement pk, basically you have to use the .create() or .save(force_insert=True) to save new instances otherwise the existance of a pk value will make the orm think you have saved it before and want to update it.  That is the main gotcha.

Would love to get some feedback before merging, however


Merged, syntax is

``` python

class NonIntPK(TestModel):
    id = PrimaryKeyField(column_class=VarCharColumn)
    name = CharField(max_length=10)
```
Issue: MyModel.create_table() doesn't use IF NOT EXISTS
Author: jerodsanto
State: closed
Created: 2011-08-22 18:00:21

The docs say that `MyModel.create_table` will noop if the table already exists, but currently it raises a `sqlite3.OperationalError` instead.

It looks like the Database class method is ready for the `safe` version, but there is no way to use that from models.

It'd be nice if you could pass the `safe` boolean to `MyModel.create_table` like you can to `MyModel.drop_table`


This is now fixed -- https://github.com/coleifer/peewee/commit/2b10102d6e4d41b2d99e16be1d83fcd3983e55a0


Awesome, thanks so much!
Issue: db_table isn't read from Meta class
Author: peterbe
State: closed
Created: 2011-03-20 16:34:52

If I do something like this:

```
    class User(peewee.Model):
         email = peewee.CharField()
         class Meta:
             db_table = 'users'
```

That doesn't get picked up. It's because none such extra arguments are actually used when creating the `_meta` attribute. See here: https://github.com/coleifer/peewee/blob/master/peewee.py#L1098


cool, pushed a testcase indicating failure, working on fix


Fix pushed in: https://github.com/coleifer/peewee/commit/981c291a83d6cb1494dfa43845db1fda56fe4028

I'm looking at scrapping the whole Meta thing as a way of munging settings because the whole thing feels fragile and janky.  May be an API update coming in the next couple days, but this should work for you.
Issue: psycopg2 should be optional
Author: JshWright
State: closed
Created: 2011-02-11 16:55:25

This is a pull request to address https://github.com/coleifer/peewee/issues/#issue/5


This would be great. Ubuntu seemed to want Postgres installed in order to satisfy psycopg through pip. I'm currently just commenting out the import locally :(


Issue fixed in https://github.com/coleifer/peewee/commit/5c5d6933e383748a99cdf5e092076a61884feebb

Thanks for reporting!!
Issue: Peewee shouldn't require multiple database libraries
Author: JshWright
State: closed
Created: 2011-02-07 18:47:56

As of 0.3.1, peewee requires _both_ psycopg2 and sqlite3, even if you only intend to use one of them.


https://github.com/coleifer/peewee/commit/5c5d6933e383748a99cdf5e092076a61884feebb
Issue: MySQL Adapter
Author: pplante
State: closed
Created: 2011-02-03 01:31:29

I added a MySQL Adapter to my fork using the new API.  I made some other small changes to integrate the two source trees.  Hopefully you can integrate this into the main library for others to enjoy.


I noticed some debug statements were left in, got them out.  Squashed a few bugs I also introduced.


i'm having a hard time telling what's new because you changed all my 4-space indentation two 2-space, which effectively shows every line as different.

if i can have the changes in the minimum of patches i'll gladly merge


I closed this because some of my changes are incompatible right now.  I will see if I can find a different way to do some of it.


For what its worth, I've got MySQL (and postgresql) support in my repo!


That's awesome to hear.  Thanks!
On Jul 17, 2011 8:18 PM, "coleifer" <
reply@reply.github.com>
wrote:

> For what its worth, I've got MySQL (and postgresql) support in my repo!
> 
> ## 
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/coleifer/peewee/pull/4#issuecomment-1592616
Issue: A small change to allow extra keyword arguments to be passed to sqlite3.connect()
Author: JshWright
State: closed
Created: 2011-01-21 17:36:02

Thanks for a great little ORM. It does exactly what I need, without getting in the way.

This pull request encompasses two small changes. The first is to use the Python 2.5 style ternary in place of the custom lambda. The second (and more important to me) change is to allow arbitrary keyword arguments to be passed to sqlite3.connect().


I applied the keyword args change, thanks!


The keyword args change uses the "native" ternary, so if your goal is to maintain Python 2.4 compatibility (which I assume is the reason for not pulling the other commit), you'll probably want to fix that.


d'oh.  you just couldn't use the old-fashioned one in your patch, could you?


Or I could have just used the short-circuit like you did... Guess I have ternary on the brain from the previous commit.

In any case, this certainly meets my needs. Thanks for pulling it.
Issue: None/NULL don't work
Author: wearpants
State: closed
Created: 2010-12-01 18:13:36

Stuffing a None into any field returns a False value when retrieved.  For example, setting a TextField to None returns '' (empty string), BooleanField returns False, etc.. 

Dunno if this intentional, (real NULL support would be nice, though IIRC django discourages it). If it is, this sentence in the docs is misleading: "Conversion between python and the database is handled transparently, including the proper handling of None/NULL." As a user of the dbapi directly, I expected storing a None to return a NULL.


Good point, this definitely looks like something that'll need fixing.  Let me look into it.


Fixed in https://github.com/coleifer/peewee/commit/466d6d7c41d4f888d6c3db5e7de55785b2c41940

Check the test case for examples.