New Repo Creation [Objectbox-Rust]

[swise0]

Enable rustlang support or integration.. since Rust is more focused on performance and memory safety

[greenrobot]

Once someone can provide some minimal useful code, we're open to create a new repo.

[damien-white]

I may be wrong, but the OP's comment seems to be a request for your organization to provide a Rust client implementation. I'm not entirely sure. I do have a hard time believing that they're insisting you rewrite your service(s) in Rust. This issue is very vague.

@swise0: are you volunteering to do the work or are you asking someone else to?

wrt the project and the organization behind it, it all looks pretty interesting. If your organization takes the initiative to get things started, I would consider contributing. It's still not clear exactly what this ticket is asking for.

[swise0]

Asking someone to 😅
The rust client

[greenrobot]

For clarification: the scope would be similar to this repo (objectbox-go), but for Rust. It would offer a Rust API (aka "frontend", "binding") on top of the core ObjectBox library (which exposes a C API). Thus, it's not a client in the client/server sense. It still would be an embedded database.

At some point @vaind experimented with ObjectBox and Rust; https://github.com/vaind/objectbox-rust is likely worth a look...

[vaind]

At some point @vaind experimented with ObjectBox and Rust; https://github.com/vaind/objectbox-rust is likely worth a look...

That was just very early development and I don't think much is in there, but feel free to use whatever you like.

[Buggaboo]

WiP rust client

I worked on the macro attributes part, aka annotations on struct fields.
This is possible now.

use objectbox;
extern crate builder;

use builder::{entity, index, transient, unique};

#[entity]
struct CorrectType {
  t_bool : bool,
  #[unique(uid=1339)]
  t_u32 : u32,
}

#[entity(uid=1337)]
struct LessEmptyTypeWithParams {
  #[index(uid=1338)]
  t_bool : bool,
  #[transient]
  t_u32 : u32,
  t_u64 : u64,
  t_double : f64,
}

I saw there was a model generator in C++.

Maybe we can reuse some of that code,
instead of repeatedly reinvent the wheel,
as we usually do, i.e. java, swift, dart etc.

Generating JSON is the easy part, feeding that
through to the bindings is a lot of work.

Feel free to fork this and continue fleshing this out.

[vaind]

The generator @Buggaboo mentions is: https://github.com/objectbox/objectbox-generator#getting-started and currently generates C/C++ and Go, and yes, it is prepared to be extended to generate more languages.

[Buggaboo]

Once someone can provide some minimal useful code, we're open to create a new repo.

Hi,

I got a minimally working work-in-progress version, many thanks to @vaind, please check out the example crate in the project workspace.
Some code might need to be outcommented first to generate the required traits etc.

I have some support for the Drop trait (read: auto memory clean up), but I haven't verified that yet with valgrind, especially in error cases. I tried to preserve the zero-copy design, by passing around slices like hot pizza.

I can't claim that it's very rusty, e.g. devoid of footguns etc., but I'm open to suggestions to make it so.

It needs a lot of polishing (a lot of dead comments and code), and there is no support for async, channels, threads or queries (yet). Maybe we should let users vote for which feature gets some attention first.

Pull requests are welcome. @greenrobot-team Please evaluate if this is worthy of starting a repo on your side, at this stage.

It's completely untested on any ARCH other than my intel chip, on my old x86_64.

As a freelancer, I wouldn't mind maintaining this as a paid gig.

[Buggaboo]

Minor update:

• Implemented basic Query features, no aliasing
  * Introduced double-free crash somewhere when passing data from ob_qb + condition + ob_query -> rust If the test is run synchronously, then a double release occurs, on Store, Opt etc. It wasn't the query.
• according to valgrind, there are some leaks in the unit tests, and suppressed errors (false positives?), and sometimes none, depending on how you run the unit tests (with/without debugger/valgrind etc.)

Question @greenrobot-team: which pointers that are exposed from the ffi interface, to build a query, should be free'd from Rust's side? Or should these be transmuted after use, for the C code to free?

[greenrobot-team]

@Buggaboo Thanks for your efforts! I think at this time we don't have any resources to support this directly, but we'll discuss this internally!

If @greenrobot has time he can maybe answer questions, my knowledge in C/Rust is very limited.

[Buggaboo]

I found the culprit for the double-free. I have to run an init function, like java's@BeforeAll thing in the unit test, but in cargo/rust. The crash is not related to the query code. The tests run succesfully sequentially. The memory issues are gone according to valgrind.