Skip to content

Conversation

@signalize
Copy link
Contributor

Solution to the "N+1 problem" when dealing with related data. By implementing the enrichCollection option within the Collection definition you can reduce the number of queries required.

changes:

  • Introduces the enrichCollection option in the collection
  • Created tests
  • Created benchmark

@codecov
Copy link

codecov bot commented Apr 16, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (9677cbb) to head (f485217).
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@            Coverage Diff            @@
##              main     #1641   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           56        56           
  Lines         1843      1849    +6     
  Branches       433       435    +2     
=========================================
+ Hits          1843      1849    +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@codecov
Copy link

codecov bot commented Apr 16, 2025

Bundle Report

Changes will increase total bundle size by 1.98kB (0.02%) ⬆️. This is within the configured threshold ✅

Detailed changes
Bundle name Size Change
@signaldb/core 220.12kB 1.98kB (0.91%) ⬆️
@signaldb/sync 152.72kB 5 bytes (0.0%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: @signaldb/sync

Assets Changed:

Asset Name Size Change Total Size Change (%)
SyncManager.d.ts 5 bytes 8.2kB 0.06%
view changes for bundle: @signaldb/core

Assets Changed:

Asset Name Size Change Total Size Change (%)
index.cjs3.js 284 bytes 30.58kB 0.94%
index3.mjs 284 bytes 30.38kB 0.94%
Collection/index.d.ts 276 bytes 14.64kB 1.92%
index.cjs2.js 281 bytes 10.09kB 2.87%
index2.mjs 265 bytes 9.9kB 2.75%
Collection/Cursor.d.ts 276 bytes 6.42kB 4.5%
.vite/manifest.json 32 bytes 6.1kB 0.53%
index.cjs18.js 4.8kB 4.98kB 2745.71% ⚠️
index18.mjs 4.8kB 4.96kB 2978.88% ⚠️
ReplicatedCollection.d.ts 57 bytes 3.7kB 1.57%
AutoFetchCollection.d.ts 57 bytes 2.62kB 2.22%
index.d.ts 14 bytes 1.39kB 1.02%
index.cjs17.js -3.7kB 1.28kB -74.22%
index17.mjs -3.81kB 1.15kB -76.76%
Collection/types.d.ts 152 bytes 1.13kB 15.59% ⚠️
index.cjs19.js -1.11kB 175 bytes -86.37%
index19.mjs -991 bytes 161 bytes -86.02%

@signalize signalize marked this pull request as draft April 16, 2025 11:20
@signalize signalize marked this pull request as ready for review April 16, 2025 12:52
@obedm503
Copy link
Contributor

Thank you for doing this. Such a good feature!

@maxnowack
Copy link
Owner

Hi @signalize, that's a really neat idea to solve the N+1 problem! 🙂
I played around with it a bit and noticed some typing issues. Currently, the returned type of an enriched query must match the type of the "unenriched" item, which can be limiting.

Also, this is quite similar to the existing ´transform´ functionality, so I’m a bit unsure about the naming. Maybe something like ´transformAll´ would better capture the intent?

I definitely see the value of this feature, but I'm not entirely sure how it should be implemented. Perhaps we could approach it more generally, like a hooking system, and introduce hooks such as ´beforeFetch´, ´afterFetch´, etc. (since ´enrichCollection´ essentially hooks into query results and modifies them).

This also seems to have some parallels to your other PR, #1618

@signalize
Copy link
Contributor Author

@maxnowack For now, i changed in to transformAll and improved the return type. Please let me know what you think 😃

@signalize signalize marked this pull request as draft May 7, 2025 07:37
@signalize signalize marked this pull request as ready for review May 7, 2025 11:17
@signalize
Copy link
Contributor Author

@maxnowack FYI, the changes from the pull request #1691 negative effects the 'transformAll' benchmark. When i decrease the amount of inserts to 1000 instead of 10000 it will work...

@maxnowack
Copy link
Owner

@signalize thanks for the hint! I addressed this issue in #1717 🙂

Copy link
Owner

@maxnowack maxnowack left a comment

Choose a reason for hiding this comment

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

I think the typings for this feature are still not as good as they should be. The return type of the Cursor methods should be completely generic and inferred by the result of transformAll (like it is for the regular item transform). In general it would be good if the implementation is more similar to the implementation of the existing transform.

@signalize signalize marked this pull request as draft May 9, 2025 12:41
@signalize signalize marked this pull request as ready for review May 9, 2025 14:16
@signalize signalize marked this pull request as draft May 9, 2025 14:19
@maxnowack
Copy link
Owner

@signalize I saw you made some changes, but then marked the PR as a draft again. So I haven't reviewed it yet. Was this a mistake and you're waiting for my review, or is there still something left to do? 😀

# Conflicts:
#	packages/base/core/CHANGELOG.md
#	packages/base/core/__tests__/Collection.bench.ts
#	packages/base/core/__tests__/Collection.spec.ts
@signalize signalize marked this pull request as ready for review October 30, 2025 22:28
@signalize signalize requested a review from maxnowack October 30, 2025 23:13
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.

3 participants