We jankily fixed this for the C# sdk for 0.5, we need to take a more wholistic approach on what we want to do here. We’re pretty sure that client side indexes should be specified in the client somehow instead of in the module
Tyler: We currently only index the column marked primary_key, which is just wrong and bad.
John note (7/11/24): I need like a spec or we need to schedule a meeting to discuss this in order for me to move forward on this. If we're no longer going to generate indexes based on primarykey then we need to change that before 1.0 as that would be an API break.
Phoebe note 2024-09-23: The design as specified in the API stability proposal is that clients get the same set of indices as the module. Future work could add index(btree = cols, client = false) or something if we determine a need for that. MVP implementations of the API stability proposal will not have real indices; they will expose interfaces for indexed queries implemented as full scans.
joshua-spacetime
commented
1 month ago
We jankily fixed this for the C# sdk for 0.5, we need to take a more wholistic approach on what we want to do here. We’re pretty sure that client side indexes should be specified in the client somehow instead of in the module
Tyler: We currently only index the column marked
primary_key, which is just wrong and bad.John note (7/11/24): I need like a spec or we need to schedule a meeting to discuss this in order for me to move forward on this. If we're no longer going to generate indexes based on
primarykeythen we need to change that before 1.0 as that would be an API break.Phoebe note 2024-09-23: The design as specified in the API stability proposal is that clients get the same set of indices as the module. Future work could add
index(btree = cols, client = false)or something if we determine a need for that. MVP implementations of the API stability proposal will not have real indices; they will expose interfaces for indexed queries implemented as full scans.