Skip to content

Commit 5722961

Browse files
Lorenzo ManganiLorenzo Mangani
Lorenzo Mangani
authored and
Lorenzo Mangani
committed
resync
2 parents 8c5e4b9 + 0e88222 commit 5722961

9 files changed

+238
-256
lines changed

.github/workflows/MainDistributionPipeline.yml

+4-1
Original file line numberDiff line numberDiff line change
@@ -19,11 +19,14 @@ jobs:
1919
duckdb_version: main
2020
ci_tools_version: main
2121
extension_name: redis
22+
exclude_archs: 'wasm_mvp;wasm_threads;wasm_eh'
23+
2224

2325
duckdb-stable-build:
2426
name: Build extension binaries
2527
uses: duckdb/extension-ci-tools/.github/workflows/[email protected]
2628
with:
2729
duckdb_version: v1.2.1
2830
ci_tools_version: v1.2.1
29-
extension_name: redis
31+
extension_name: redis
32+
exclude_archs: 'wasm_mvp;wasm_threads;wasm_eh'

CMakeLists.txt

+5-1
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,11 @@ include_directories(
1515
${Boost_INCLUDE_DIRS}
1616
)
1717

18-
set(EXTENSION_SOURCES src/redis_extension.cpp)
18+
# Add redis_secret.cpp to the sources
19+
set(EXTENSION_SOURCES
20+
src/redis_extension.cpp
21+
src/redis_secret.cpp
22+
)
1923

2024
build_static_extension(${TARGET_NAME} ${EXTENSION_SOURCES})
2125
build_loadable_extension(${TARGET_NAME} " " ${EXTENSION_SOURCES})

docs/README.md

+12-146
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,12 @@
33
# DuckDB Redis Client Extension
44
This extension provides Redis client functionality for DuckDB, allowing you to interact with a Redis server directly from SQL queries.
55

6+
> Experimental: USE AT YOUR OWN RISK!
7+
<img src="https://github.com/user-attachments/assets/46a5c546-7e9b-42c7-87f4-bc8defe674e0" width=250 />
8+
9+
# DuckDB Redis Client Extension
10+
This extension provides Redis client functionality for DuckDB, allowing you to interact with a Redis server directly from SQL queries.
11+
612
> Experimental: USE AT YOUR OWN RISK!
713
814
## Features
@@ -16,6 +22,8 @@ Currently supported Redis operations:
1622
```sql
1723
INSTALL redis FROM community;
1824
LOAD redis;
25+
INSTALL redis FROM community;
26+
LOAD redis;
1927
```
2028

2129
## Usage
@@ -37,6 +45,7 @@ CALL redis_create_secret('redis_cloud', {
3745
});
3846
```
3947

48+
### String Operations
4049
### String Operations
4150
```sql
4251
-- Set a value
@@ -47,10 +56,13 @@ SELECT redis_get('user:1', 'my_redis') as user_name;
4756

4857
-- Set multiple values in a query
4958
INSERT INTO users (id, name)
59+
SELECT id, redis_set(
60+
INSERT INTO users (id, name)
5061
SELECT id, redis_set(
5162
'user:' || id::VARCHAR,
5263
name,
5364
'my_redis'
65+
'my_redis'
5466
)
5567
FROM new_users;
5668
```
@@ -153,149 +165,3 @@ Planned features include:
153165
- Batch operations using Redis pipelines
154166
- Connection timeout handling
155167

156-
# DuckDB Extension Template
157-
This repository contains a template for creating a DuckDB extension. The main goal of this template is to allow users to easily develop, test and distribute their own DuckDB extension. The main branch of the template is always based on the latest stable DuckDB allowing you to try out your extension right away.
158-
159-
## Getting started
160-
First step to getting started is to create your own repo from this template by clicking `Use this template`. Then clone your new repository using
161-
```sh
162-
git clone --recurse-submodules https://github.com/<you>/<your-new-extension-repo>.git
163-
```
164-
Note that `--recurse-submodules` will ensure DuckDB is pulled which is required to build the extension.
165-
166-
## Building
167-
### Managing dependencies
168-
DuckDB extensions uses VCPKG for dependency management. Enabling VCPKG is very simple: follow the [installation instructions](https://vcpkg.io/en/getting-started) or just run the following:
169-
```shell
170-
cd <your-working-dir-not-the-plugin-repo>
171-
git clone https://github.com/Microsoft/vcpkg.git
172-
sh ./vcpkg/scripts/bootstrap.sh -disableMetrics
173-
export VCPKG_TOOLCHAIN_PATH=`pwd`/vcpkg/scripts/buildsystems/vcpkg.cmake
174-
```
175-
Note: VCPKG is only required for extensions that want to rely on it for dependency management. If you want to develop an extension without dependencies, or want to do your own dependency management, just skip this step. Note that the example extension uses VCPKG to build with a dependency for instructive purposes, so when skipping this step the build may not work without removing the dependency.
176-
177-
### Build steps
178-
Now to build the extension, run:
179-
```sh
180-
make
181-
```
182-
The main binaries that will be built are:
183-
```sh
184-
./build/release/duckdb
185-
./build/release/test/unittest
186-
./build/release/extension/<extension_name>/<extension_name>.duckdb_extension
187-
```
188-
- `duckdb` is the binary for the duckdb shell with the extension code automatically loaded.
189-
- `unittest` is the test runner of duckdb. Again, the extension is already linked into the binary.
190-
- `<extension_name>.duckdb_extension` is the loadable binary as it would be distributed.
191-
192-
### Tips for speedy builds
193-
DuckDB extensions currently rely on DuckDB's build system to provide easy testing and distributing. This does however come at the downside of requiring the template to build DuckDB and its unittest binary every time you build your extension. To mitigate this, we highly recommend installing [ccache](https://ccache.dev/) and [ninja](https://ninja-build.org/). This will ensure you only need to build core DuckDB once and allows for rapid rebuilds.
194-
195-
To build using ninja and ccache ensure both are installed and run:
196-
197-
```sh
198-
GEN=ninja make
199-
```
200-
201-
## Running the extension
202-
To run the extension code, simply start the shell with `./build/release/duckdb`. This shell will have the extension pre-loaded.
203-
204-
Now we can use the features from the extension directly in DuckDB. The template contains a single scalar function `quack()` that takes a string arguments and returns a string:
205-
```
206-
D select quack('Jane') as result;
207-
┌───────────────┐
208-
│ result │
209-
│ varchar │
210-
├───────────────┤
211-
│ Quack Jane 🐥 │
212-
└───────────────┘
213-
```
214-
215-
## Running the tests
216-
Different tests can be created for DuckDB extensions. The primary way of testing DuckDB extensions should be the SQL tests in `./test/sql`. These SQL tests can be run using:
217-
```sh
218-
make test
219-
```
220-
221-
## Getting started with your own extension
222-
After creating a repository from this template, the first step is to name your extension. To rename the extension, run:
223-
```
224-
python3 ./scripts/bootstrap-template.py <extension_name_you_want>
225-
```
226-
Feel free to delete the script after this step.
227-
228-
Now you're good to go! After a (re)build, you should now be able to use your duckdb extension:
229-
```
230-
./build/release/duckdb
231-
D select <extension_name_you_chose>('Jane') as result;
232-
┌─────────────────────────────────────┐
233-
│ result │
234-
│ varchar │
235-
├─────────────────────────────────────┤
236-
│ <extension_name_you_chose> Jane 🐥 │
237-
└─────────────────────────────────────┘
238-
```
239-
240-
For inspiration/examples on how to extend DuckDB in a more meaningful way, check out the [test extensions](https://github.com/duckdb/duckdb/blob/main/test/extension),
241-
the [in-tree extensions](https://github.com/duckdb/duckdb/tree/main/extension), and the [out-of-tree extensions](https://github.com/duckdblabs).
242-
243-
## Distributing your extension
244-
To distribute your extension binaries, there are a few options.
245-
246-
### Community extensions
247-
The recommended way of distributing extensions is through the [community extensions repository](https://github.com/duckdb/community-extensions).
248-
This repository is designed specifically for extensions that are built using this extension template, meaning that as long as your extension can be
249-
built using the default CI in this template, submitting it to the community extensions is a very simple process. The process works similarly to popular
250-
package managers like homebrew and vcpkg, where a PR containing a descriptor file is submitted to the package manager repository. After the CI in the
251-
community extensions repository completes, the extension can be installed and loaded in DuckDB with:
252-
```SQL
253-
INSTALL <my_extension> FROM community;
254-
LOAD <my_extension>
255-
```
256-
For more information, see the [community extensions documentation](https://duckdb.org/community_extensions/documentation).
257-
258-
### Downloading artifacts from GitHub
259-
The default CI in this template will automatically upload the binaries for every push to the main branch as GitHub Actions artifacts. These
260-
can be downloaded manually and then loaded directly using:
261-
```SQL
262-
LOAD '/path/to/downloaded/extension.duckdb_extension';
263-
```
264-
Note that this will require starting DuckDB with the
265-
`allow_unsigned_extensions` option set to true. How to set this will depend on the client you're using. For the CLI it is done like:
266-
```shell
267-
duckdb -unsigned
268-
```
269-
270-
### Uploading to a custom repository
271-
If for some reason distributing through community extensions is not an option, extensions can also be uploaded to a custom extension repository.
272-
This will give some more control over where and how the extensions are distributed, but comes with the downside of requiring the `allow_unsigned_extensions`
273-
option to be set. For examples of how to configure a manual GitHub Actions deploy pipeline, check out the extension deploy script in https://github.com/duckdb/extension-ci-tools.
274-
Some examples of extensions that use this CI/CD workflow check out [spatial](https://github.com/duckdblabs/duckdb_spatial) or [aws](https://github.com/duckdb/duckdb_aws).
275-
276-
Extensions in custom repositories can be installed and loaded using:
277-
```SQL
278-
INSTALL <my_extension> FROM 'http://my-custom-repo'
279-
LOAD <my_extension>
280-
```
281-
282-
### Versioning of your extension
283-
Extension binaries will only work for the specific DuckDB version they were built for. The version of DuckDB that is targeted
284-
is set to the latest stable release for the main branch of the template so initially that is all you need. As new releases
285-
of DuckDB are published however, the extension repository will need to be updated. The template comes with a workflow set-up
286-
that will automatically build the binaries for all DuckDB target architectures that are available in the corresponding DuckDB
287-
version. This workflow is found in `.github/workflows/MainDistributionPipeline.yml`. It is up to the extension developer to keep
288-
this up to date with DuckDB. Note also that its possible to distribute binaries for multiple DuckDB versions in this workflow
289-
by simply duplicating the jobs.
290-
291-
## Setting up CLion
292-
293-
### Opening project
294-
Configuring CLion with the extension template requires a little work. Firstly, make sure that the DuckDB submodule is available.
295-
Then make sure to open `./duckdb/CMakeLists.txt` (so not the top level `CMakeLists.txt` file from this repo) as a project in CLion.
296-
Now to fix your project path go to `tools->CMake->Change Project Root`([docs](https://www.jetbrains.com/help/clion/change-project-root-directory.html)) to set the project root to the root dir of this repo.
297-
298-
### Debugging
299-
To set up debugging in CLion, there are two simple steps required. Firstly, in `CLion -> Settings / Preferences -> Build, Execution, Deploy -> CMake` you will need to add the desired builds (e.g. Debug, Release, RelDebug, etc). There's different ways to configure this, but the easiest is to leave all empty, except the `build path`, which needs to be set to `../build/{build type}`. Now on a clean repository you will first need to run `make {build type}` to initialize the CMake build directory. After running make, you will be able to (re)build from CLion by using the build target we just created. If you use the CLion editor, you can create a CLion CMake profiles matching the CMake variables that are described in the makefile, and then you don't need to invoke the Makefile.
300-
301-
The second step is to configure the unittest runner as a run/debug configuration. To do this, go to `Run -> Edit Configurations` and click `+ -> Cmake Application`. The target and executable should be `unittest`. This will run all the DuckDB tests. To specify only running the extension specific tests, add `--test-dir ../../.. [sql]` to the `Program Arguments`. Note that it is recommended to use the `unittest` executable for testing/development within CLion. The actual DuckDB CLI currently does not reliably work as a run target in CLion.

duckdb

Submodule duckdb updated 1576 files

src/include/redis_extension.hpp

+2-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
#pragma once
22

33
#include "duckdb.hpp"
4+
#include "redis_secret.hpp"
45

56
namespace duckdb {
67

@@ -10,4 +11,4 @@ class RedisExtension : public Extension {
1011
std::string Name() override;
1112
};
1213

13-
} // namespace duckdb
14+
} // namespace duckdb

src/include/redis_secret.hpp

+14
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
#pragma once
2+
3+
#include "duckdb/main/secret/secret.hpp"
4+
#include "duckdb/main/secret/secret_manager.hpp"
5+
#include "duckdb/main/extension_util.hpp"
6+
7+
namespace duckdb {
8+
9+
class CreateRedisSecretFunctions {
10+
public:
11+
static void Register(DatabaseInstance &instance);
12+
};
13+
14+
} // namespace duckdb

0 commit comments

Comments
 (0)