SQL-DB

[squirrelo]

HTML view of the schema at https://dl.dropboxusercontent.com/u/39899821/qiita-db.html

[antgonza]

Capitalize What

[adamrp]

In study_pmid table, pmid is a varchar

[adamrp]

Now, a couple general comments:

• We have nothing in the database currently for logging. We discussed this once or twice, and I think it's a really good idea to get in ASAP (possibly blocking this)
• We should carefully consider which foreign keys should have ON DELETE CASCADE and/or ON UPDATE CASCADE and add them where necessary

[squirrelo]

+1

[squirrelo]

Where are we on this? Major questions right now:

Do we want to add the logging tables now?
Do we want to add the comments on tables now?
When are we doing the cascade stuff?

[wasade]

not sure on points 2 and 3, but if we do not do logging now then it is a
pipe dream to think that it will ever actually go in

On Fri, Apr 11, 2014 at 11:22 AM, Joshua Shorenstein <
[email protected]> wrote:

Where are we on this? Major questions right now:

Do we want to add the logging tables now?
Do we want to add the comments on tables now?
When are we doing the cascade stuff?

Reply to this email directly or view it on GitHubhttps://github.com//pull/32#issuecomment-40227918
.

[squirrelo]

Right, so then we need to figure out what logging tables we need and how to put them together. Can we get that done before Tuesday?

[wasade]

at the minimum, something like:

create table log_details (
log_id bigserial not null,
time datetime not null,
user_id not null, -- we may want to allow null here
severity_id int not null, -- fk into a severity table
msg varchar not null, -- the reason this is being logged
)

...with the appropriate indices of course. The reason we may want a null
user is for system events that are not tied to a specific user. We may want
to allow one or two other fields, but that above is what i believe the bare
minimum. Once this table is in place, we can then also put appropriate
logging mechanisms in place in our base classes so we can reduce the amount
of developer thought that is necessary to actually use the logging system

On Fri, Apr 11, 2014 at 11:29 AM, Joshua Shorenstein <
[email protected]> wrote:

Right, so then we need to figure out what logging tables we need and how
to put them together. Can we get that done before Tuesday?

Reply to this email directly or view it on GitHubhttps://github.com//pull/32#issuecomment-40228671
.

[squirrelo]

user_id for system calls can be explicitly system that way we can query and also have not null. I'm trying to have as many not null columns as possible so we don't run into the problems of the current database of not adding things that are important because they aren't explicitly required.

May also be a good idea to log what the user was doing when it screwd up, i.e. a task column.

[squirrelo]

Another column that we discussed was logging a dev error vs a user error vs a run error. This might be able to wrap into the severity info.

[wasade]

re: user_id, depends if we want granularity for what system threw the error

On Fri, Apr 11, 2014 at 11:38 AM, Joshua Shorenstein <
[email protected]> wrote:

user_id for system calls can be explicitly system that way we can query
and also have not null. I'm trying to have as many not null columns as
possible so we don't run into the problems of the current database of not
adding things that are important because they aren't explicitly required.

May also be a good idea to log what the user was doing when it screwd up,
i.e. a task column.

Reply to this email directly or view it on GitHubhttps://github.com//pull/32#issuecomment-40229482
.

[wasade]

whats the difference between a dev error and a run error?

On Fri, Apr 11, 2014 at 11:46 AM, Joshua Shorenstein <
[email protected]> wrote:

Another column that we discussed was logging a dev error vs a user error
vs a run error. This might be able to wrap into the severity info.

Reply to this email directly or view it on GitHubhttps://github.com//pull/32#issuecomment-40230579
.

[squirrelo]

I have no idea, it's in my notes as that.

[squirrelo]

Added logging table and two columns for password reset. This should be good to go now? HTML also reflects the changes.

[squirrelo]

Do we want users to verify email before allowing login? That requires two more columns on the qiita_user table if so.

[antgonza]

Not really, we can use the user_level_id to define that is not verified.

Is there something missing from this PR?

[squirrelo]

Not any more as far as I can tell.

[teravest]

I think this is good to merge and get us moving. we can always change
things later.

On Mon, Apr 14, 2014 at 2:31 PM, Joshua Shorenstein <
[email protected]> wrote:

Not any more as far as I can tell.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/32#issuecomment-40414352
.

[wasade]

exciting!

On Tue, Apr 15, 2014 at 6:25 AM, Antonio Gonzalez
[email protected]:

Merged #32 #32.

Reply to this email directly or view it on GitHubhttps://github.com//pull/32
.

[squirrelo]