mengw15 commented on PR #6016: URL: https://github.com/apache/texera/pull/6016#issuecomment-5030822888
On the test stalemate: I'm all for moving dataset search into file-service — but that's a big refactor of its own (`SearchQueryBuilder`/`DashboardResource` are shared with the workflow/project builders, which haven't migrated, so dataset search can't move alone). I'd rather do that migration + its tests as one dedicated PR later, and just cover this bug now. And it can be covered now, as a plain unit test, because the dedup lives one layer below `searchAllResourcesCall`. `DatasetSearchQueryBuilder.constructQuery` returns a jOOQ query and touches neither `DashboardResource` nor LakeFS — only the full path does (via `toEntryImpl` → `LakeFSStorageClient`). A query-level spec, same shape as `WorkflowResourceSpec`: - `MockTexeraDB` embedded Postgres + `initializeDBAndReplaceDSLContext()` - insert a public dataset (user A) + a `DATASET_USER_ACCESS` row (user B) - `DatasetSearchQueryBuilder.constructQuery(uidB, params, includePublic = true).fetch()`, assert row count == 1 (was 2 before the fix) Real SQL runs (the bug is a JOIN fan-out, so a real DB is needed — embedded, not external), but `toEntryImpl`/LakeFS and `DashboardResource` are never reached, so it stays a unit test: no live storage, no `unmanagedSources`. It also hits the changed `constructFromClause` lines directly (likely why patch coverage reads ~9% today), and since it only needs `DatasetSearchQueryBuilder` it survives the eventual move unchanged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
