Data storage for angular app JSON

[gebeer]

Hi Folks,

I am currently building an angular app for creating and displaying polls/surveys: http://embed.plnkr.co/seQfprxQRvjg84bvi2Dy/

The data that needs to be stored in PW comes from JSON and looks like

{
  "title": "My Survey",
  "questions": [
    {
      "id": 1,
      "title": "First Question",
      "answers": [
        {
          "id": 1,
          "title": "Answer 1"
        },
        {
          "id": 2,
          "title": "Answer 2"
        }
      ]
    }
  ],
  "file": {
    "$ngfName": "long-beach-koh-payam.jpg",
    "$ngfOrigSize": 351901,
    "$ngfBlobUrl": "blob:http://localhost:8000/8b87de97-549a-4900-8579-71a0d87a9258"
  }
}

Now I need to decide how to best store that data with PW. I am also using Angular to build the forms where users can submit the poll from the JSON that is produced by the survey builder. So I would like to create 1 page per poll. The template holds title field, an image file field and one field that stores the data as JSON string.

To me this seems an easier approach than having child pages for each question in the poll and again child pages for each answer to a question.

Do you see any disadvantages that this approach might bring?

And which field type should I use to store the JSON string, textarea?

[tpr]

For JSON storage I'm using a render and renderValue hook that turns a textarea to formatted table layout in my form submissions:

It works quite well, the only disadvantage is that you can't search entries like 'email=...' because there are only 1 field (json_storage). But I guess you don't need this feature anyway.

I can share the code if you wish, though it's part of a module so it's not that easy to decouple.

[kongondo]

Yes, a plain textarea works best for this. I use the same technique in Menu Builder. Form Builder also stores data as JSON. Same as @tpr, the main disadvantage I see is searching. 

So I would like to create 1 page per poll. The template holds title field, an image file field and one field that stores the data as JSON string.

What's you rationale for 1 page per poll? Why not 1 page per question? With the former, it is a bit difficult to compare how a specific question was answered. I guess it all depends on what you want to do with the survey afterwards. 

To me this seems an easier approach than having child pages for each question in the poll and again child pages for each answer to a question.

I don't understand this. What are these child pages? What is their parent page?

At the end of the day, it really depends on 1) scalability 2) what you are after. Are the individual users the main object of your study? i.e. are you mainly interested in what 'John' said as compared to 'Mary'? Or, are the questions themselves the most important thing, e.g. 'Drink A tests better than drink B', 'Car X is better than can Y'. Easier approach is not always best approach. When it comes to analysing your data you want that to be as most efficient as possible. It might not have been 'easier' to set up, but it will provide a more meaningful insight into the data (plus maybe easier to maintain) than the 'easier' way . I guess what I am saying is that it's hard to give a definitive answer because it's not clear what you want to do with the data in the end (and also how you want it maintained). The answer to that/these question(s) might mean it is better to use pages instead; or it is better to use JSON or even custom SQL tables.

Just my 2p

[gebeer]

@tpr
thanks for the insight and for your offer. I don't think I really need that code
 
@kongondo
thank you for your confirmation on textarea being a good chopice for JSON storage and for the other considearations
 

What's you rationale for 1 page per poll? Why not 1 page per question? With the former, it is a bit difficult to compare how a specific question was answered. I guess it all depends on what you want to do with the survey afterwards.

1 page per poll because here I only store the JSON that is produced by the survey builder and will be used to render the poll form.
The submitted poll results will be sent to a different PW install and stored there. There I will store poll id and for each user submission the question/answer ids in a table pro field. Later I can pull this data, analyse it and present it in graphs using t3 library.
 

I don't understand this. What are these child pages? What is their parent page?

Example:
-parent page poll
--child page question1
---child page answer1
---child page answer2
--child page question2
---child page answer1
---child page answer2
 

At the end of the day, it really depends on 1) scalability 2) what you are after. Are the individual users the main object of your study? i.e. are you mainly interested in what 'John' said as compared to 'Mary'? Or, are the questions themselves the most important thing, e.g. 'Drink A tests better than drink B', 'Car X is better than can Y'. Easier approach is not always best approach. When it comes to analysing your data you want that to be as most efficient as possible. It might not have been 'easier' to set up, but it will provide a more meaningful insight into the data (plus maybe easier to maintain) than the 'easier' way . I guess what I am saying is that it's hard to give a definitive answer because it's not clear what you want to do with the data in the end (and also how you want it maintained). The answer to that/these question(s) might mean it is better to use pages instead; or it is better to use JSON or even custom SQL tables.

I'm more after 'Drink A tests better than drink B'. So I will store the submitted results like described above.

[bernhard]

Hi gebeer,

Sounds like a very interesting project! Would be great to have some insights in the showcase section when you're done

[gebeer]

@bernhard

actually this is a long ongoing project which is already online. I am constantly implementing new features. But the project is hard to showcase because most of the stuff happens inside a frontend member-area which requires login. I have been planning to showcase this for some time now and I might go with screenshots. But ATM I do not have the capacities to document it thoroughly. Though this might happen at some point, I can't tell when.

Anyways, feel free to use the code for the Survey Builder in the plunk that I linked to. I will implement that as a PW module for the project and will share that module once it is up and running.

[Pierre-Luc]

By the way I believe MySQL 5.7 has a JSON format that can be queried, probably wouldn't be too hard to build a field type around it.

[adrian]

By the way I believe MySQL 5.7 has a JSON format that can be queried, probably wouldn't be too hard to build a field type around it.

Cool, I hadn't seen this yet - could be very handy!