-
Notifications
You must be signed in to change notification settings - Fork 18
Fix sequence deletion after nextval call #26
base: master
Are you sure you want to change the base?
Conversation
agscpp
commented
Sep 24, 2024
|
Hi, @gmoshkin . Can you please take a look at my pull request? |
|
Hi, thanks for the patch! Could you explain, how are the provided SQL commands related to the test?
The code in question will not be invoked when this SQL is executed. Could you also add a test, so that we don't break the fix accidentally in the future. |
|
This is an abstract example that I used to compare the behavior with other DBMSs. Okay, I'll write tests for this logic. |
2c81c42 to
8cca8d2
Compare
|
@gmoshkin |
|
Also please update |
8cca8d2 to
f1187e6
Compare
tests/src/box.rs
Outdated
| let mut seq = Sequence::find("test_drop_seq").unwrap().unwrap(); | ||
| assert_eq!(seq.next().unwrap(), 1); | ||
|
|
||
| tarantool::schema::sequence::drop_sequence(2).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the test! There's a problem though, this hard-coded id is volatile as it may change if another test is added (if someone adds another sequence). We could make it much more robust if we got the id from the Sequence struct. Unfortunately there's currently no method for this, but it's very easy to add it.
Do you mind adding fn id(&self) -> u32 for the Sequence struct and using it in this test?
This will also be potentially useful for other users of tarantool-module as it will allow explicit deletion of sequences, by adding the ability to get the id of the instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I wrote this comment yesterday, but failed to submit the review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have corrected the code based on your comments. Please take a look again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
f1187e6 to
b45cd7c
Compare
|
@gmoshkin |
This is a continuation of work done in commit 52bb62c. This time the problem arose after a recent change in rustc, and resulted in lua exceptions stopping being intercepted by tarantool. I don't know yet what's the specific cause of this, what changed in rust and how did it affect the seemingly unrelated functionality of tarantool, but this change seems to help. Here's how the problem showcased in the tests: running 1 test test tlua::functions_write::error ... #1 0x16378a7 in tarantool_panic_handler+103 #2 0x183eaf5 in lj_err_throw+117 #3 0x183ee65 in lj_err_run+277 #4 0x183f63f in lua_error+15 #5 0x7673285fc50a in ??+0 #6 0x1834373 in lj_BC_FUNCC+70 #7 0x183b295 in lua_pcall+117 #8 0x76732868f87d in ??+0 #9 0x7673286adea5 in ??+0 #10 0x7673289e1acc in ??+0 #11 0x7673289e15ae in ??+0 #12 0x7673289e0f9c in ??+0 #13 0x7673289dedfb in ??+0 #14 0x7673289ced2c in ??+0 #15 0x76732858b414 in ??+0 #16 0x7673285a1659 in ??+0 #17 0x16920eb in module_func_call+139 #18 0x17b4ba3 in lbox_func_call+307 #19 0x1834373 in lj_BC_FUNCC+70 #20 0x183b295 in lua_pcall+117 #21 0x16411ef in luaT_call+15 #22 0x16381f1 in lua_main+97 #23 0x1638ab1 in run_script_f+2193 #24 0x165c3e1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+17 #25 0x15beea7 in fiber_loop+55 #26 0x1618f68 in coro_init+72 2025-02-10 19:39:05.410 [3087063] main/104/run_tests.lua C> your message: my message