Question: Do you plan to port your features back to original RepoDB?

[AntyaDev]

Hi! Thanks for maintaining this fork.

I was wondering if you have any plans to contribute or port some of the features you've added in this fork back to the original RepoDB project. There are some really useful improvements here, and I'm curious whether you see them eventually becoming part of the main project, or if you intend to keep them exclusive to the fork.

Thanks!

[JanBrandenburger-LSF]

I actually feel a bit ashamed.
@rhuijben has put so much effort and time into taking over the project, and I’m so incredibly grateful to him for that.
In Germany, we say he “saved our butts.”
Switching everything over to a new technology would have taken months for our 20 projects.
Now the lead developer has resurfaced and is really hitting his stride. And Bert´s work is being forgotten a little bit.

I don’t know to what extent he and Bert are in contact.
I too, would be interested to know what will happen with the fork, or whether it will be merged back.

So, just a big THANK YOU for all your time, Bert!

[rhuijben]

Not sure yet... I'm not in active contact with @mikependon, but I do know he knows about this fork. Some of my initial changes are already merged in the new RepoDB release, but most of the more recent refactorings are not.

The license allows re-use, but merging feature by feature will be a huge undertaking. The forks will probably co-exist for quite some time.

[rhuijben]

At my day job we currently rely on some of the extensions here:

• the multikey primary key support
• Tvp support for sqlserver IN (@..) queries, which allow more internal optimizations.
  These require changes in the core layers; not too invasive, but changes anyway.
• Improved type mappings in SQLite.microsoft, to support more sqlserver like operations (bool, date types, etc)

Most other changes (like the expression fixes, and vector support) could be ported as small fixes with the related tests.

The statement builder changes for multikey primary key and related, could be quite big but are limited to lower layers. The user surface wasn't changed much.

[mikependon]

Cool that all can be applied to the core ORM. It is not much of capability changes, but is more about enhancements. Will you be able to port it back to the main? Some of them are also in our limitations which we can actually start looking and improve further the library.

It is important to not change the current Integration Tests as we are not introducing breaking changes. We can add more Integration Tests to cover these new scenarios.

Will you be able to write these as issue (Enhancement)? Separate them as 3 entries and we collaborate to each. You can also issue the PR right away in every story.

[mikependon]

I made quite an effort there to support the Bulk operations for Oracle already, it works very well. But I am interested to know which specific use-case you had improved in Oracle that is not part of my end-to-end support.

[rhuijben]

I have the *All operations working using the required Oracle construct for batching on my fork, while batchsize on master was 1 last time I checked.

[mikependon]

Can you PR that mate to the master?

[AntyaDev]

@rhuijben @mikependon
I think I saw some improvements regarding JSON support.
Probably here: #25

[rhuijben]

I used some AI to summarize the most important work on the fork as separate steps in https://b.qqn.nl/f/2026/repodb/ (the zip file contains the separate text files)
This might help somebody who has more spare time than me port some things before I can.

Time estimates are 100% AI, and unlikely to match to any proper estimates. Some simple regex search&replace operations are guessed at weeks.

// CC: @mikependon

[mikependon]

After today is a right time as I already pushed the v1.16.0 releases and will make the anouncement later. We may be able to start revisiting few reported issues for the community. This could also be one of it. Let us see.

[mikependon]

@rhuijben @AntyaDev are you able to join to RepoDB teams at here?