nickva edited a comment on pull request #3050:
URL: https://github.com/apache/couchdb/pull/3050#issuecomment-666737359
Saw some unexpected success test failures:
```
fabric2_db_crud_tests:40: crud_test_ (recreate_db)...*failed*
in function fabric2_db_crud_tests:'-recreate_db/1-fun-4-'/1
(test/fabric2_db_crud_tests.erl, line 160)
in call from fabric2_db_crud_tests:recreate_db/1
(test/fabric2_db_crud_tests.erl, line 160)
**error:{assertException,
[{module,fabric2_db_crud_tests},
{line,160},
{expression,"fabric2_db : get_db_info ( Db1 )"},
{pattern,"{ error , database_does_not_exist , [...] }"},
{unexpected_success,
{ok,[{cluster,{[{n,0},{q,0},{r,...},{...}]}},
{compact_running,false},
{data_size,0},
{db_name,<<"eunit-te"...>>},
{disk_format_version,0},
{disk_size,0},
{instance_start_time,...},
{...}|...]}}]}
output:<<"">>
```
From
https://github.com/apache/couchdb/blob/prototype/fdb-layer/src/fabric/test/fabric2_db_crud_tests.erl#L160
So perhaps the existing code wasn't totally wrong. The question is what
should happen if we end up finding a previous instance of a db in the cache.
With the current PR we'll let the user roll with the old db, and when they
perform a transaction operation, we'd silently upgrade it to the new db
version. And then they can keep holding on that stale handle and be none the
wiser.
In the previous scheme, any old db handle immediately threw a
`database_does_not_exist` error which bubbled up to the client right away. That
wasn't correct either, since a user may delete and recreate the db on node1
then make a re-quest for db_info to node2, get the previous db instance, then
get a 404 response, which is wrong.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
