Skip to content

Magic IndexedDB v2.0.0-alpha8
Compare
Choose a tag to compare
@magiccodingman magiccodingman released this 02 Jun 16:03
· 19 commits to master since this release
v2.0.0-alpha8
0d11953

Magic IndexedDB v2.0.0-alpha8

Special thanks to @Ard2025 for their significant help in this patch. A ton of core functionality has been cleaned up, fixed, and clarified—especially around cursor queries and interface enforcement. Here's what's new:

NuGet: Magic.IndexedDb v2.0.0-alpha8

Core Fixes

  • Blazor Server yield safety fixed
    The JavaScript message size variable was not being correctly implemented. This has now been fixed, ensuring safe and reliable streaming of large result sets via .AsAsyncEnumerable()—especially in Blazor Server mode. Related to #79

  • Indexable .OrderBy() was crashing
    A missing logic set was preventing indexable .OrderBy() queries from executing correctly. This has now been resolved. Indexed ordering now works as expected and no longer crashes when used correctly. related to #92

Cursor Query Syntax Fully Fixed

Several cursor query operations were broken and causing infinite loops. A new shared helper class was introduced to reduce duplicate logic and unify the behavior between cursor and indexable query extensions.

The following cursor methods are now fully fixed and tested:

  • .OrderBy()
  • .OrderByDescending()
  • .Skip()
  • .Take()
  • .TakeLast()
  • .FirstOrDefault()
  • .LastOrDefault()

All have unit tests and consistent cursor behavior.

Interface Enforcement Update – No More Accidental Cursor Guarantees

The .Where(x => x) interface is designed to provide a non-zero chance of triggering indexable queries—it's not guaranteed, but it's safe.

However, an oversight allowed this anti-pattern:

query.Where(x => x).OrderBy(x => ...)

This breaks IndexedDB’s capabilities, because once you append .OrderBy() after a .Where(), the result is no longer indexable. Previously, Magic IndexedDB silently corrected this by switching to a cursor, but it should have been disallowed by the interface itself.

This has now been fixed. You can no longer append .OrderBy() after a .Where() in the optimized path.

If you need full control (e.g. combining .Where() and .OrderBy() freely), use .Cursor() instead to unlock the meta-driven query engine.

Learn more about how and when to use .Cursor() here:
https://sayou.biz/Magic-IndexedDB/Blazor/Blazor-Where-Vs-Cursor

Documentation Updates

Cursor vs Where — Blazor-Specific Docs Now Live

A brand new guide is available explaining the difference between .Where() and .Cursor() in C# Blazor:
https://sayou.biz/Magic-IndexedDB/Blazor/Blazor-Where-Vs-Cursor

Skip Before Take — Fully Explained

A commonly reported confusion (Issue #85) has now been formally documented.

This is not a bug—it's an intentional behavior in Magic IndexedDB based on how IndexedDB itself works.

Read the explanation:
https://sayou.biz/Magic-IndexedDB-Why-Take-Then-Skip

Thank you to everyone using Magic IndexedDB. This release tightens guarantees, improves correctness, and reinforces what makes the system so powerful: performance with safety-first design. 🚀

Contributors

Ard2025
Assets 2
Loading