numerals/rollcall

An application that keeps track of your attendance.

Sartaj Singh

@leosartaj

That would confuse things.

Ghost

@ghost~550d34c415522ed4b3dd96cb

Otherwise, it's like having a table for every day.

Sartaj Singh

@leosartaj

sql slows things down, as told by @mafiya69.

Also we have some json related functions.

Ghost

@ghost~550d34c415522ed4b3dd96cb

It won't, if we have just one table.

Also, I'm thinking that it would be a install time configurable option.

Completely optional.

Sartaj Singh

@leosartaj

Now, that shouldn't be asked from users.

This will scare people.

Keep it under the hoods.

Ghost

@ghost~550d34c415522ed4b3dd96cb

Many packages do such stuff.

Sartaj Singh

@leosartaj

What I find good with json is, in my credit you can ask for raw data. And i just give you the json.

Ghost

@ghost~550d34c415522ed4b3dd96cb

Ipython notebook only opens when you have 4 other packages installed, which are optional dependencies.

Sartaj Singh

@leosartaj

hmm...Why do you think it will be good, to have json and sql?

Ghost

@ghost~550d34c415522ed4b3dd96cb

A lot of work will go to waste. Also, we might want to shift over to sql if we want more features.

Sartaj Singh

@leosartaj

Yes. That's a nice point.

Ok, what I say is finalise the json.

We then map it into tables.

Ghost

@ghost~550d34c415522ed4b3dd96cb

:+1:

Sartaj Singh

@leosartaj

This is confirmed, one table contains all the subject names with a unique id.

Ghost

@ghost~550d34c415522ed4b3dd96cb

We can also go crazy with layers.

{
    "subjects": {
        "name": id
    },
    "classes": {
        "semester": {
            "month": {
                "week": {
                    "date": {
                        "period_id": ("subject_id", "status")
                    }
                }
            }
        }
    }
}

Sartaj Singh

@leosartaj

Oh my.

Ghost

@ghost~550d34c415522ed4b3dd96cb

Semester, month, week & date can be added as columns.

Sartaj Singh

@leosartaj

Better will be sql table I gues. Too much of nesting

Ghost

@ghost~550d34c415522ed4b3dd96cb

Yeah. That's too much nesting.

Sartaj Singh

@leosartaj

So second table is classes.

Ghost

@ghost~550d34c415522ed4b3dd96cb

Yeah.

Sartaj Singh

@leosartaj

Columns - period_id(unique), subject_id, date, status

That will do?

Ghost

@ghost~550d34c415522ed4b3dd96cb

We can use a simple hash for period_id

Sartaj Singh

@leosartaj

And semester to divide things up

Ghost

@ghost~550d34c415522ed4b3dd96cb

A bidirectional hash.

Sartaj Singh

@leosartaj

Man, why not simple 1, 2, 3?

Ghost

@ghost~550d34c415522ed4b3dd96cb

No date, we calculate the period_id in such a way that it determines the date too.

Sartaj Singh

@leosartaj

If we are into sql. Why not keep it simple?

Ghost

@ghost~550d34c415522ed4b3dd96cb

Well, the date would be repeated many times.

Sartaj Singh

@leosartaj

Yeah. But it's sql.

It's common.

Ghost

@ghost~550d34c415522ed4b3dd96cb

Also, that simplifies the json to this:

{
    "subjects": {
        "name": id
    },
    "classes": {
        "period_id": ("subject_id", "status")
    }
}

Sartaj Singh

@leosartaj

That will be good for json your idea.

In sql, I say we keep it simple

Querying will be easy that way

Ghost

@ghost~550d34c415522ed4b3dd96cb

Yeah, well they can be different :smile:

Sartaj Singh

@leosartaj

So, final json or sql?

Json we already have it merged.

Sql, well we will need to.

Ghost

@ghost~550d34c415522ed4b3dd96cb

I'm thinking that this json is good.

Where communities thrive

People

Repo info

Activity