I have a module for which I've created a custom table in the database. I want to access various data in the table.

Since normally accessing content types is done via the abstraction layer provided by Drupal itself I'm wondering what would be the most "drupal" way to access the data in my table.

I assume I could simply use Database::connection class and function, but it seems a tad brutal(so to speak).

Would it make sense to create a repository or am I just overthinking this and should just go ahead and use the Database class and be done with it.

  • An answer would be really great. You can go into a bit more details not to mention I can accept it. – Andrew May 3 '17 at 10:07

If this question was about D7, you could start from what's suggested in the Developers Guide that comes with the Forena module (disclosure: I'm a co-maintainer of the D7 version). Here is a quote from its introduction:

Forena implements custom hooks to allow the report engine to be extended in many ways. Forena does use OOP methodologies, but also leverages the observer pattern so prevalent in Drupal.

There is then a common pattern that is used to extend Forena:

  • Implement a custom php class that lives in your module directory. You may extend any of the Forena classes, or write your own from scratch.
  • Implement the expected registration methods in your class (e.g. templates, formats).
  • In your module implement a hook (e.g. mymodule_forena_controls) that tells Forena the location of your class definition file.

These days, Forena has a dev version for D8 also, for which it's current status can be summarized like so (from it's release notes):

Basic rendering of reports and document types are complete, however the GUI version of the report writer has not yet been ported. Sufficed to say, this version can be used by Drupal 8 report writers who are comfortable writing .frx files and sql elements by hand.

Some more details to help you digest these release notes:

  • "SQL elements" refers to Data Blocks and the Data Sources they relate to, as explained in the Data Guide.
  • The ".FRX files" are the actual specifications of how you want you report to look like, as explained in the FRX Reporting Reference.
  • The "GUI version of the report writer" is what is explained in the WYSIWYG Reporting Guide.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.