Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop trying to get last_insert_id() from all the columns #122

Closed
wants to merge 1 commit into from
Closed

Stop trying to get last_insert_id() from all the columns #122

wants to merge 1 commit into from

Conversation

khmarochos
Copy link

Hello,

When we're trying to create a new row in a table having a complex PK (like int+datetime+datetime in my case), we're getting a Can't get last insert id exception, as datetime doesn't return anything to a last_insert_id call, so @pri_values != @missing_pri in such case.

So I'd like to propose to filter out the columns that don't have the is_auto_increment attribute set. Would you be so kind as to review it? Thanks!

@ribasushi
Copy link
Collaborator

Hi @Melnik13, sorry for the late reply. The change you suggest would seriously affect drivers that use the value-prefetches as opposed to relying on last_insert_id directly.

In general your description is a bit unclear, specifically:

having a complex PK (like int+datetime+datetime )

Could you share the actual primary key definition and the actual types/names( important ) of the columns involved? Ideally just seeing the entire CREATE TABLE ... statement would be best

@khmarochos
Copy link
Author

khmarochos commented Jan 24, 2018

Hello,

Thank you for your time.

I have tables of temporal (bi-temporal, to more precise) data, so a record's states usually imply multiple rows indicating all the states of each record in time. That's why I decided to make a triple PK (id + known_from + valid_from).

I was too innocent thinking it would be a wise idea to identify a record by a triple of fields only. Actually, I implemented it in my database, but then I had to reconsider the id field as a single-column PK and adde an XXX_id (where XXX is the same as the table's name) column to identify the instance. It turned out to be giving some pain in further developments, so I had to fall back to the idea of the single-columned PK (identifying a row itself).

Anyhow, thank you for your attention. Will be looking forward for more cool news about the project, I'm a big fan and a grateful user of DBIx::Class. :)

@ribasushi
Copy link
Collaborator

Well, there is still a bug here in the sense that nothing threw a warning that what you are doing won't really work. I will keep this open for the time being to remind myself it needs addressing.

Glad you got your immediate problem solved though!

@khmarochos khmarochos closed this by deleting the head repository Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants