Database Query Fails for Stores with Special Characters in Name or Properties

[KariHall619]

Description:
When attempting to execute a database query through the Data Manager UI, the query fails to execute or returns an unexpected error. This issue is observed when a Store, configured via the "Create Store" UI with special characters (e.g., &, #, ?, spaces) in its Name or custom Properties (keys/values), is selected and used for querying.
The expected behavior is that the database query tool should successfully connect to and query the database regardless of special characters used in the Store's configuration parameters, assuming these characters are valid for the underlying database and operating system, and are handled correctly by atest. Queries should function as they would for a Store configured without such special characters.

repro step:

1.Create a new Store via the "Create Store" UI with the following parameters:
Name: My Prod&Test DB
URL: jdbc:postgresql://localhost:5432/mydatabase
Username: testuser
Password: testpassword
Plugin Name: atest-store-orm
Properties:
Key: charSet?
Value: UTF-8#strict

2.Verify and Submit the Store. The Store creation might appear successful.
3.Navigate to the Data Manager view.
4.Select the newly created Store: My Prod&Test DB.
5.Select the target database instance (if applicable for the plugin).
6.Enter a simple SQL query, for example: SELECT * FROM users LIMIT 10;
7.Click "Execute".
8.Observed Behavior:
An error message is displayed (e.g., "Failed to execute query: Connection not found" or "Invalid store configuration" or the query UI hangs indefinitely).
Checking the atest backend logs might show errors related to parsing the store name or properties, or an inability to find the connection details.

Possible reason:(?)
It's possible that the encoding or escaping mechanism for Store names and their custom properties, when being passed from the frontend to the backend, or when the backend retrieves and uses these configurations for establishing a database connection, might have been inadvertently changed. This could lead to misinterpretation of these special characters, causing the backend to fail in correctly identifying or utilizing the Store's connection parameters. The issue might lie in how these string values are handled, potentially being truncated, improperly escaped, or causing parsing errors when used to build connection strings or lookup keys.

[KariHall619]

Looks like it's struggling with those characters when trying to connect. My gut says it's an encoding/escaping thing somewhere between the UI and when the backend tries to use that config. I'll poke around there first...

[KariHall619]

Okay, found something major! It turns out the Query function in both fileLoader.go and nonLoader.go basically just says 'nope, not supported' or does nothing at all.
Here's the snippet from fileLoader.go:

func (l *fileLoader) Query(query map[string]string) (result DataResult, err error) { result.Pairs = map[string]string{ "message": "not support", // <-- This is it! } return }

And nonLoader.go is similar – just an empty return.
So, if your setup happens to be using the fileLoader (like for local test suites) or the nonLoader, the database query tool in the UI is designed to not work, period. This isn't about the special characters in the Store name anymore; it's a fundamental limitation for these loader types.
This explains why queries would fail in certain environments, even if the special character issue for Store names also exists as a separate bug. We're hitting this 'not supported' wall first if those loaders are active.

[KariHall619]

Let me fix it... :)