Piccolo

------

``Update`` queries without a ``where`` clause
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you try and perform an update query without a ``where`` clause you will now
get an error:

.. code-block:: python

>>> await Band.update({Band.name: 'New Band'})
UpdateError

If you want to update all rows in the table, you can still do so, but you must
pass ``force=True``.

.. code-block:: python

>>> await Band.update({Band.name: 'New Band'}, force=True)

This is a similar to ``delete`` queries, which require a ``where`` clause or
``force=True``.

It was pointed out by theelderbeever that an accidental mass update is almost
as bad as a mass deletion, which is why this safety measure has been added.

See `PR 412 <https://github.com/piccolo-orm/piccolo/pull/412>`_.

.. warning:: This is a breaking change. It you're doing update queries without
a where clause, you will need to add ``force=True``.

``JSONB`` improvements
~~~~~~~~~~~~~~~~~~~~~~

Fixed some bugs with nullable ``JSONB`` columns. A value of ``None`` is now
stored as ``null`` in the database, instead of the JSON string ``'null'``.
Thanks to theelderbeever for reporting this.

See `PR 413 <https://github.com/piccolo-orm/piccolo/pull/413>`_.

-------------------------------------------------------------------------------

------

create_user
~~~~~~~~~~~

``BaseUser`` now has a ``create_user`` method, which adds some extra password
validation vs just instantiating and saving ``BaseUser`` directly.

.. code-block:: python

>>> await BaseUser.create_user(username='bob', password='abc123XYZ')
<BaseUser: 1>

We check that passwords are a reasonable length, and aren't already hashed.
See `PR 402 <https://github.com/piccolo-orm/piccolo/pull/402>`_.

async first
~~~~~~~~~~~

All of the docs have been updated to show the async version of queries.

For example:

.. code-block:: python

Previous:
Band.select().run_sync()

Now:
await Band.select()

Most people use Piccolo in async apps, and the playground supports top level
await, so you can just paste in ``await Band.select()`` and it will still work.
See `PR 407 <https://github.com/piccolo-orm/piccolo/pull/407>`_.

We decided to use ``await Band.select()`` instead of ``await Band.select().run()``.
Both work, and have their merits, but the simpler version is probably easier
for newcomers.

-------------------------------------------------------------------------------

------

In Piccolo you can print out any query to see the SQL which will be generated:

.. code-block:: python

>>> print(Band.select())
SELECT "band"."id", "band"."name", "band"."manager", "band"."popularity" FROM band

It didn't represent ``UUID`` and ``datetime`` values correctly, which is now fixed (courtesy theelderbeever).
See `PR 405 <https://github.com/piccolo-orm/piccolo/pull/405>`_.

-------------------------------------------------------------------------------

------

Using descriptors to improve MyPy support (`PR 399 <https://github.com/piccolo-orm/piccolo/pull/399>`_).

MyPy is now able to correctly infer the type in lots of different scenarios:

.. code-block:: python

class Band(Table):
name = Varchar()

MyPy knows this is a Varchar
Band.name

band = Band()
band.name = "Pythonistas" MyPy knows we can assign strings when it's a class instance
band.name MyPy knows we will get a string back

band.name = 1 MyPy knows this is an error, as we should only be allowed to assign strings

-------------------------------------------------------------------------------

------

Fixed bug with ``BaseUser`` and Piccolo API.

-------------------------------------------------------------------------------

------

The ``BaseUser`` table hashes passwords before storing them in the database.

When we create a fixture from the ``BaseUser`` table (using ``piccolo fixtures dump``),
it looks something like:

.. code-block:: json

{
"id": 11,
"username": "bob",
"password": "pbkdf2_sha256$10000$abc123",
}

When we load the fixture (using ``piccolo fixtures load``) we need to be
careful in case ``BaseUser`` tries to hash the password again (it would then be a hash of
a hash, and hence incorrect). We now have additional checks in place to prevent
this.

Thanks to mrbazzan for implementing this, and sinisaos for help reviewing.

-------------------------------------------------------------------------------