Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>My general rule of thumb is to keep the data in your database as "pure" as possible, and do any sanitization, rendering, escaping or general munging as close to the user as possible - typically in a helper method or the view, in a Rails app.</p> <p>This has served me well for several reasons:</p> <ul> <li>Different representations of your data may have display requirements - if you implement a console interface at some point, you won't want to have all that html sanitization.</li> <li>Keeping all munging as far out from the database as possible makes it clear whose responsibility it is to sanitize. Many tools or new developers maintaining your code may not realize that strings are already sanitized, leading to double-escaping and other formatting ugliness. This also applies to the "different representations" problem, as things can end up escaped in multiple different ways.</li> <li>When you look in your database by hand, which will end up happening from time to time, it's nice to see things in their un-munged form.</li> </ul> <p>So, to address your specific project, I would suggest having your users enter their text as Markdown and storing it straight in to the database, without the <code>before_save</code> hook (which, as an aside, would be called on creation or update, so you wouldn't also need a <code>before_update</code> hook unless there was something specific that you wanted on update but not creation). I would then create a helper method, maybe <code>santize_markdown</code>, to do your sanitization. You could then call your helper method on the raw markdown, and generate your body html from the sanitized markdown. This could go in the view or in another helper method according to your taste and how many different places you were doing it, but I probably wouldn't put it in the model since it's so display-specific.</p>
    singulars
    1. This table or related slice is empty.
    1. POSimple model of blog post
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USJohn Hyland
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI agree with the general approach re:markdown. But, I think that sanitization can and should be done before storage. Assuming you use a whitelist approach to input, there is some data you just don't want in your system at all. I tend to sanitize user input on create, altering the user-data accordingly, but escape and processing still occur on view.
      singulars
      1. PO
      1. USToby Hede
    2. COHm. It seems to me that splitting your input munging to do some pre-storage and some post-storage is adding complexity and the possibility of confusion as to what happens when. What sort of data do you find universally and urgently bad enough to warrant that kind of split?
      singulars
      1. PO
      1. USJohn Hyland
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload