Skip to content

Conversation

@amoeba
Copy link
Member

@amoeba amoeba commented Nov 13, 2025

Fixes an issue where the driver install location wasn't showing up when a user runs dbc search -v on Windows. This was only impacting user and system level installs and the reason we didn't catch this is that we don't test those levels in CI.

This PR updates the Windows code paths that set the FileInfo member on the DriverInfo struct so it's set to the registry root for the appropriate level. We just weren't setting it before for registry user and system levels. I went with the registry key root instead of the location of the DLL because the driver is really installed to the registry and we don't want users thinking they can uninstall a driver from %APPDATA% or something.

Here's an example of what this looks like on my system:

• sqlite
   Title: ASF SQLite Driver
   Description: An ADBC driver for SQLite developed under the Apache Software Foundation
   License: Apache-2.0
   Installed Versions:
    ╰── 1.8.0
        ├── system => HKEY_LOCAL_MACHINE\SOFTWARE\ADBC\Drivers
        ├── env => C:\Users\Bryce\src\columnar-tech\dbc
        ╰── user => HKEY_CURRENT_USER\SOFTWARE\ADBC\Drivers
   Available Versions:

Closes #203

@amoeba amoeba requested a review from zeroshade November 13, 2025 21:50

// For drivers in the registry, set FilePath to the registry key instead
// of the filesystem path since that's technically where the driver exists.
di.FilePath = fmt.Sprintf("%s\\%s", lvl.rootKeyString(), regKeyADBC)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we have k and dkey, can't we get the full key names from those instead of needing the new function?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried and failed to get a name from the k (which appears to be just a handle not a rich object). I'll try again though since it'd be nice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, you're right. That really sucks, there's no way to get the current name of the key from the handle.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked again and I don't see how. It looks like keys are comparable so we can at least simplify it a bit. I'd be happy if you took a look at the package too just in case I'm missing something.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See 106e5c3

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hrm, maybe not. the new change results in this,

   Installed Versions:
    ╰── 1.8.0
        ├── user => UNK\SOFTWARE\ADBC\Drivers
        ├── system => UNK\SOFTWARE\ADBC\Drivers
        ╰── env => C:\Users\Bryce\src\columnar-tech\dbc

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, my first attempt I was comparing the wrong handles. But comparing the right handles would require changing the function signature of driverInfoFromKey or moving setting FileInfo out of driverInfoFromKey. So driverInfoFromKey unfortunately has to be modified.

I like what I have now enough. Take another look?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any way we can add a test for this? otherwise, this looks good to me

@zeroshade
Copy link
Member

This was only impacting user and system level installs and the reason we didn't catch this is that we don't test those levels in CI.

Should we add tests for CI for this case?

@amoeba
Copy link
Member Author

amoeba commented Nov 15, 2025

This was only impacting user and system level installs and the reason we didn't catch this is that we don't test those levels in CI.

Should we add tests for CI for this case?

Yeah we should. I'll resurrect the PR for testing user and system, IIRC it's basically ready.

@amoeba
Copy link
Member Author

amoeba commented Nov 15, 2025

Latest output

• sqlite
   Title: ASF SQLite Driver
   Description: An ADBC driver for SQLite developed under the Apache Software Foundation
   License: Apache-2.0
   Installed Versions:
    ╰── 1.8.0
        ├── user => HKCU\SOFTWARE\ADBC\Drivers
        ╰── system => HKLM\SOFTWARE\ADBC\Drivers

@amoeba
Copy link
Member Author

amoeba commented Nov 15, 2025

Let me file another PR to fix the test failure.

@amoeba
Copy link
Member Author

amoeba commented Nov 15, 2025

Filed as #212. We can merge that first if we want.

@amoeba amoeba requested a review from zeroshade November 15, 2025 01:42
@amoeba amoeba force-pushed the fix/windows-missing-driver-paths branch from e997658 to cda221d Compare November 17, 2025 16:32
@amoeba
Copy link
Member Author

amoeba commented Nov 17, 2025

Rebased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

dbc search -v does not print paths to installed drivers on Windows

2 participants