Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict DB query abstraction to the Datastore module #3823

Open
dafeder opened this issue Aug 23, 2022 · 2 comments
Open

Restrict DB query abstraction to the Datastore module #3823

dafeder opened this issue Aug 23, 2022 · 2 comments
Assignees
Milestone

Comments

@dafeder
Copy link
Member

dafeder commented Aug 23, 2022

We use AbstractDabaseQuery in several places throughout DKAN, but this is really just an additional database abstraction layer on top of Drupal's. We have no plans to ever implement DKAN as a standalone application outside of Drupal, so this adds an unnecessary amount of complexity to the codebase.

Currently, we have an abstract notion of a data query that is used in a few places around DKAN. We also have a concept of a Datastore Query, which is slightly different. So we first convert incoming datastore query objects to generic DKAN "queries", then run them through our abstracted storage classes to convert them to db queries that Drupal can actually execute.

To make this all more efficient and easy to work with:

  1. Collapse the above-mentioned code flow for the datastore. We should eliminate "QueryFactory" and "Abstract Database Table", and simply pass the incoming Datastore query directly to a modified version of the SelectFactory, cutting out the middlemen completely. (Will make a second pass at this issue and spec this out in more detail - @dafeder.)
  2. Refactor the Jobstore service to use the Drupal DB API directly, eliminating the DKAN storage classes from that part of the code.
  3. Refactor the Harvest service to eliminate the "Storage" layer and make Drupal DB API calls as needed.
  4. Refactor the ResourceMapper service to use Drupal DB API calls as needed

It may make sense to separate the storage logic somewhat in these cases and create an interface around them, but let's minimize the abstractions and add simple code that works.

@dafeder dafeder added this to the 3.x milestone Aug 23, 2022
@janette janette modified the milestones: 3.x, 2023 Q3 Feb 18, 2023
@paul-m
Copy link
Contributor

paul-m commented Jan 29, 2024

In progress. Internal: 16902

@dafeder dafeder self-assigned this Apr 5, 2024
@dafeder
Copy link
Member Author

dafeder commented Apr 5, 2024

Making a note to link this to recent work refactoring various things as Drupal entities which gets us closer to being able to do this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants