0

On change(using AJAX) of Job title the text area will show and admin will enter text in admin form. By using system_settings_form I am storing values in DB using Variables.

PROBLEM:

  1. I have more than 20 values in the dropdown.
  2. For this I need to store the textarea values in a variable.
  3. This leads to huge values stored in variable table.

Is there any other way rather than using this, or is this the best way of using?

I am just checking all the possibilities.

Any Ideas will be much appreciated, Thanks.

enter image description here

4
  • 2
    You can use your own submit function, and store the values in a custom table. But is there some reason for this? What are your concerns?
    – Jaypan
    Sep 27, 2016 at 9:41
  • Yeh i agree to use custom table. But jus for storing few values I would suggest to go with variable it self. So, I thought of is there something beyond this.
    – NTT
    Sep 27, 2016 at 9:45
  • @Nagarjuna: All you really have is the database so its pretty much either a custom table or the variables table. It's up to you which option you deem appropriate in which situation. You can also store a serialized array in a single variable if you use a custom submit handler.
    – rooby
    Sep 27, 2016 at 10:10
  • There are 3 options. 1) Creating new entity 2) Working with ctools export api 3) Custom table with your own read write helper function.
    – Jimmy Ko
    Sep 27, 2016 at 10:16

1 Answer 1

1

You can store your data wherever you like, in whatever format you like, and you can manage it in any way that php allows; Drupal doesn't have an opinion on the matter.

If you're asking whether Drupal has another variable API you can use for this slightly different requirement, then no it doesn't.

So to answer your question directly

Is there any other way to store values in DB other than 'system_settings_form'

Yes, just use the database API in whatever way you think is appropriate for the data you're storing/retrieving. Various modules provide data layers, e.g. ctools has a data API as Jimmy mentioned in the comments. There's also the core entity API, but that's going to be overkill for your needs.

All that said, you might want to actually profile your code to see if 20 values serialised into a single row is going to cause you any real problems. Yours and MySQL's definition of "huge" might be quite different.

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.