I don't think it would. You set the id in model, it's passed to database,
and then database returns it back again
Some of the database adapters require an additional round-trip to retrieve
the newly-inserted ID; this doesn't happen if an id was supplied at record
creation. Others (like MySQL) will fall back on the DB's built in "last
inserted ID" mechanism, which doesn't work if you are generating IDs
manually (`mysql_insert_id`, for instance, only gets a value if the id
column was AUTO_INCREMENT).
For more detail, keep tracing from where you quoted. `_create_record` calls
which does two things:
* if the primary key is empty and the adapter wants to use prefetch, it
generates an ID
* explicitly selects the supplied (or generated) primary key value and
passes it as a separate argument to the `insert` method in the connection
The default implementation of the connection adapter's `insert` method:
will automatically return the value passed in as `id_value`, if present.
The MySQL and Postgres versions appear to do this as well.
A workaround for your case would be database-specific; for instance, on
MySQL I'd recommend that you ensure the trigger sets `LAST_INSERT_ID` and
then extract the value from the DB directly (via `SELECT LAST_INSERT_ID()`)
in an `after_create`. Unfortunately, the ID is the one field that the
standard, DB-independent approach to dealing with trigger-supplied data
(calling `reload` after saving) won't work for.
Dne pátek 21. srpna 2015 17:26:49 UTC+2 masa331 napsal(a):