Add sqlite resource

[Ughuuu]

• Fixes Database as resource #164

[2shady4u]

@Ughuuu I'll review this asap

One minor thing that I noticed is that only ".db" is a valid extension at the moment, while for SQLite, the actual extension doesn't actually matter. Some people seem to prefer using ".database" or even don't use any extension at all.

I solved this issue a long time ago by adding the default_extension property such that users can choose whatever extension they want.

Is this something that can be supported in some way?

[Ughuuu]

I wouldn't know. From my knowledge I know it's possible to use hardcoded extensions.
One option would be to have project settings (eg. SQLite/default_extension) and have the user put there setting and then require a restart(a popup if the option requires a restart). And have it be an array, and by default be only [".db"]

[Ughuuu]

Oh, I see, right now default extension is a property on the node. Hm.
I wonder why not just use the path variable, what is the purpose of the extension. It would simplify a bit the whole design if defaultProperty were a global setting instead of a node setting.

[Ughuuu]

But for now, as to not make breaking changes, I can just add a defaultExtension property on the project settings inside:
filesystem/import/sqlite/default_extension

[2shady4u]

Hello @Ughuuu 😄

I've had some time to review the MR and here are my comments:

• Move the new source files to a new resource/-folder (similar to the vfs/- and sqlite/-folders)
• For some reason the new default_extension-setting only shows up if you enable the "Advanced Settings" button. Is it possible to make it so that it shows up without having to enable this?
• Is there any reason why the new default_extension property in the ProjectSettings should be a PackedStringArray? I think I would prefer to have it as a simple String instead (for now).
• I don't think there's any point in having the get_content()-method in the SQLiteResource? Or is there some hidden mechanism that I don't know about? Same with the constructor and destructor in the SQLiteResource class?

I can see that integrating this resource even tighter into the main SQLite would definitely make sense, but that would break backwards compatibility.

[Ughuuu]

• For default_extension(maybe i can rename to default_extensions:

Just so that if someone has files with multiple extensions, eg .db and .database its easier to support this now rather than later have a breaking change.

For rest i will check and implement feedback.

Agree with integration, i am thinking of making a higher level node, eg sqlite viewer, where you put a sqliteresource and you can view database schema and values with pagination, maybe.

Maybe we can make another property also on sqlite eg sqlite_resource and keep the path also. And have if you put path that takes precedence(so its also backwards compatible)

[2shady4u]

• For default_extension(maybe i can rename to default_extensions:

Just so that if someone has files with multiple extensions, eg .db and .database its easier to support this now rather than later have a breaking change.

For rest i will check and implement feedback.

Agree with integration, i am thinking of making a higher level node, eg sqlite viewer, where you put a sqliteresource and you can view database schema and values with pagination, maybe.

Maybe we can make another property also on sqlite eg sqlite_resource and keep the path also. And have if you put path that takes precedence(so its also backwards compatible)

Not super-important, but is there any way to disallow the user from inputting "" as an extension?

Tighter integration would be the next step, but I think it's best to keep the scope of this PR like it is for now though 😄