These fields were stored. That usually is good, but if you add partners to an event from the wizard, it means each `res.partner` record gets its `registration_count` field updated.

When you update any record, fields `write_uid` and `write_date` are updated too.

Now imagine you want to add 4000 partners to an event. That would take time. If in the mean time any other user updates the `res.partner` record (along with their `write_UID` and `WRITE_DATE` fields), you would get this error:

```
openerp.sql_db: bad query: UPDATE "res_partner" SET "registration_count"=3,"write_uid"=5,"write_date"=(now() at time zone 'UTC') WHERE id IN (25578)
Traceback (most recent call last):
  File "/opt/odoo/common/openerp/v8/openerp/sql_db.py", line 234, in execute
    res = self._obj.execute(query, params)
TransactionRollbackError: could not serialize access due to concurrent update
CONTEXT:  SQL statement "SELECT 1 FROM ONLY "public"."res_users" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x"
```

By removing the `store=True` parameter, you simply avoid those concurrent updates and do not block other users.

But this changes the database structure, so remember to update your database!

…CA#48)

If adding 1000 partners, we save now 999 queries.

(cherry picked from commit 89853ef)

Currently translated at 100.0% (24 of 24 strings)

Translation: event-12.0/event-12.0-partner_event
Translate-URL: https://translation.odoo-community.org/projects/event-12-0/event-12-0-partner_event/es/

…oint

For speeding up the process. Specially the removal of the savepoints
makes that Postgres don't go slow as hell. Check
https://www.cybertec-postgresql.com/en/subtransactions-and-performance-in-postgresql/
for some rationale. The problem happens even releasing the previous
savepoints.

As this module is very old, the reason for doing it this way and skip
registrations with error is not fully known, but the view mentions about
registration duplication, so let's avoid it and handle later other
possible exceptions.

TT26694

When we confirm a sale order, the registrations are precreated without
the email info, so we were missing the chance to get the info for the
partner attendant.

Now we compute it on the write as well.

TT45149