Bug: I upgraded my server surreal version and lost all my data about surrealdb

[phughk]

Hi @mimib00, can you confirm that the rocksdb file storage has the same file size still?

[mimib00]

Hi @mimib00, can you confirm that the rocksdb file storage has the same file size still?

Yeah that's the weird thing the data was still on the disk but surrealdb 1.4.2 and surrealist 2.0.5 can't see it for some reason

I have edited the main bug question with more details you can check it

[kearfy]

Hey @mimib00, did you upgrade from v1.0.0? Or perhaps one of it's beta's

[mimib00]

Hey @mimib00, did you upgrade from v1.0.0? Or perhaps one of it's beta's

The database was in 1.0.0 and updated to v1.4.2 using docker-compose

[phughk]

@mimib00 can you confirm the docker volumes you have please?

[mimib00]

he docker volumes you have please?

what do you mean by that?

if you mean that the volume exists and has permissions it does cause as soon as I reverted the database version in the docker-compose file to 1.0 every worked just fine and the data is there

[phughk]

Could you please export the 1.0 database and import it into the latest (either 1.4 or 1.5).

I was wondering if it was the case that a separate image would have had separate storage, explaining the above.

Either way, exporting and importing should solve the problem, whatever the underlying infra issue is. The data will only disappear if it isn't found.

[mimib00]

I'm busy with other projects at the moment, but I'll give it a try as soon as I'm free and update you here

[nathanschwarz]

@mimib00 there's a bug I also encountered on Surrealist when upgrading surrealDB versions. In my case the data is not lost, Surrealist just can't show the results in the UI, if you manually query your data you should be able to see it.

[mimib00]

@phughk

AN update on this issue so, I have just finished the migration of this project from version 1.0 to 1.5.1 and now it is working just fine but there is another bug with the data types here is an example of a query:

SELECT is_new, email FROM users WHERE email=$email

now in v1.0 it was working just fine but after I upgraded to v1.5.1 the query didn't return anything after some debugging I found that surrealdb is not registering the email as a string and if I ran the same query but like this:

SELECT is_new, email FROM users WHERE email=type::string($email)

It works just fine, I did more digging and tried this query:

LET $user = SELECT * FROM users:iaMwpm1QCBdtmFKGLaOZGCLENNe2;
type::is::string($user.email); // returns false even tho it's a string in the table schema.

but the weird thing is that this happens only on the database that has been migrated from 1.0 to 1.5.1 cause I have a dev db that was created newly with 1.5.1 the above query is working just fine with it.

[mimib00]

@phughk

AN update on this issue so, I have just finished the migration of this project from version 1.0 to 1.5.1 and now it is working just fine but there is another bug with the data types here is an example of a query:

SELECT is_new, email FROM users WHERE email=$email

now in v1.0 it was working just fine but after I upgraded to v1.5.1 the query didn't return anything after some debugging I found that surrealdb is not registering the email as a string and if I ran the same query but like this:

SELECT is_new, email FROM users WHERE email=type::string($email)

It works just fine, I did more digging and tried this query:

LET $user = SELECT * FROM users:iaMwpm1QCBdtmFKGLaOZGCLENNe2;
type::is::string($user.email); // returns false even tho it's a string in the table schema.

but the weird thing is that this happens only on the database that has been migrated from 1.0 to 1.5.1 cause I have a dev db that was created newly with 1.5.1 the above query is working just fine with it.

BTW this also created this same issue with strings with the full-text search where now I need to use type::string() with every variable in the query