| *** aelkner has quit IRC | 08:53 | |
| *** aelkner has joined #schooltool | 09:06 | |
| *** alga has joined #schooltool | 13:24 | |
| *** ignas has joined #schooltool | 14:43 | |
| *** replaceafill has joined #schooltool | 16:23 | |
| *** th1a has joined #schooltool | 16:29 | |
| th1a | hi aelkner, replaceafill, y..., m... | 16:31 |
|---|---|---|
| th1a | Lithuanian holiday? | 16:31 |
| replaceafill | good morning | 16:31 |
| aelkner | morning | 16:32 |
| th1a | Ah, I see the email. | 16:32 |
| th1a | OK, good. | 16:32 |
| th1a | I mainly needed to talk to you guys anyhow. | 16:33 |
| th1a | (I guess only I got the email) | 16:33 |
| th1a | yvl sick, menesis vacation day. | 16:33 |
| aelkner | next meeting ed? | 16:34 |
| aelkner | wed | 16:34 |
| th1a | Of course. | 16:34 |
| aelkner | well, they may have said tomorrow | 16:34 |
| th1a | Update replaceafill? | 16:34 |
| replaceafill | i've been working on the translation of the book, which allowed me to find several bugs | 16:35 |
| replaceafill | in the app and the book | 16:35 |
| th1a | I'm going to have to finish the book this week. | 16:35 |
| replaceafill | i reported like 4 last week | 16:35 |
| replaceafill | some related to i18n issues | 16:35 |
| replaceafill | i created a branch for my translation | 16:36 |
| replaceafill | wanted to ask menesis a couple of things | 16:36 |
| replaceafill | related to putting the book online | 16:36 |
| replaceafill | and about the spanish text of schooltool in the ubuntu software center | 16:37 |
| replaceafill | i'll wait for wednesday meeting | 16:37 |
| th1a | Ah yes, translations for the software center. | 16:37 |
| th1a | Good point. | 16:37 |
| replaceafill | yes | 16:37 |
| replaceafill | th1a, could you review my 3 last revisions on https://code.launchpad.net/~schooltool-owners/schooltool-book/flourish | 16:38 |
| replaceafill | some typos i found | 16:38 |
| replaceafill | and grammar issues | 16:38 |
| replaceafill | basically, that's it, i'm around 40-50% completed | 16:38 |
| replaceafill | (the book is big!) :) | 16:38 |
| th1a | OK. I subscribed myself too. | 16:38 |
| replaceafill | th1a, ah cool | 16:39 |
| replaceafill | i think that's it, will keep reporting things as i find them | 16:39 |
| replaceafill | btw | 16:39 |
| th1a | kk | 16:39 |
| replaceafill | someone from barcelona wrote to the mailing list | 16:39 |
| replaceafill | maybe they will use the spanish translation of the book someday :) | 16:40 |
| th1a | Hopefully. | 16:40 |
| replaceafill | ok, that's it from me | 16:40 |
| replaceafill | i think i'll be done by wed with the translation | 16:41 |
| th1a | OK. | 16:41 |
| th1a | Thanks replaceafill. | 16:41 |
| th1a | aelkner? | 16:41 |
| aelkner | you saw my email to david welsh, so until he finds something else, i'm done with that | 16:42 |
| aelkner | the one bug that i saw douglas create that perhaps i could take is: | 16:43 |
| aelkner | https://bugs.launchpad.net/schooltool.gradebook/+bug/898831 | 16:43 |
| aelkner | that should be a simple one | 16:43 |
| aelkner | do you have anything else in mind? | 16:43 |
| th1a | Do that one. | 16:43 |
| th1a | And then you're on to new features for a while. | 16:43 |
| aelkner | is there any bugs filed for feature requests? | 16:44 |
| th1a | We will be discussing that now. | 16:44 |
| aelkner | ok | 16:45 |
| th1a | So basically, you're going to be moving onto Journal for a while. | 16:45 |
| th1a | But I suspect you'd prefer to do gradebook stuff first. | 16:45 |
| aelkner | that's a very informed guess :) | 16:45 |
| *** replaceafill has left #schooltool | 16:46 | |
| th1a | OK, so just to prepare yourself mentally, you're going to be doing a lot of Journal work in the not too distant future. | 16:46 |
| *** replaceafill has joined #schooltool | 16:46 | |
| th1a | So you won't be shocked. ;-) | 16:46 |
| replaceafill | sorry, closed the wrong window | 16:46 |
| aelkner | th1a, that's fine | 16:46 |
| th1a | The big gradebook related feature is sets of activities. | 16:47 |
| aelkner | interesting | 16:47 |
| aelkner | how is that? | 16:47 |
| th1a | OK here's the thing -- this is going to be part of the gradebook module -- it is obviously completely dependent on gradebook. | 16:47 |
| th1a | But the more you think of it as separate from actual gradebooks the better it is going to go. | 16:47 |
| th1a | Unless that's not really possible because of the design of the gradebook... | 16:48 |
| th1a | So basically you need to be able to save a set of activities. | 16:48 |
| th1a | So that you can share them. | 16:48 |
| th1a | They might be in a person's "activity library" | 16:48 |
| th1a | Well... I guess where the canonical version lives is an open question. | 16:49 |
| th1a | But the point is that you need to be able to attach them to a course. | 16:49 |
| aelkner | a design need, yes | 16:49 |
| aelkner | starting from what we have now | 16:49 |
| th1a | So that if you want, each course in the school has the same set of activities. | 16:49 |
| th1a | That is, the same worksheet. | 16:49 |
| aelkner | ah, by course | 16:50 |
| aelkner | IActivities(course) could be added, taking advantage of what we know aqbout IActivities(section) | 16:50 |
| th1a | Or, a teacher might have a view of their "activity library" and select one set of activities to apply to one or more worksheets. | 16:50 |
| aelkner | IActivities(person)? | 16:51 |
| th1a | Maybe? | 16:51 |
| aelkner | point being, that adapter currently returns a list of worksheets | 16:51 |
| aelkner | no reason we could do the same for course and person | 16:51 |
| aelkner | then the user could select a worksheet from the course or person | 16:52 |
| aelkner | i mean 'no reason we could not...' - double negatives :) | 16:52 |
| th1a | Probably a worksheet should also be an activity set by default. | 16:52 |
| aelkner | a worksheet is already a set of activities, so we can use that | 16:53 |
| aelkner | but since IAcitivites is a set of worksheets, we can use that as well | 16:53 |
| th1a | Yeah, I guess maybe these are all worksheets or a worksheet base class (or something) | 16:53 |
| replaceafill | th1a, https://bugs.launchpad.net/schooltool.gradebook/+bug/544944 | 16:53 |
| replaceafill | that's it right? | 16:53 |
| th1a | Yes. | 16:54 |
| th1a | I'm trying to think of it a bit more abstractly though. | 16:54 |
| aelkner | yes, that's the user request | 16:54 |
| aelkner | and i agree that abstractly, it doesn't need to be limited to the user request | 16:55 |
| th1a | Maybe I'm overthinking it a bit. | 16:55 |
| aelkner | i don't thing so | 16:55 |
| aelkner | think | 16:55 |
| aelkner | probably better to generalize than just fix the one request | 16:55 |
| th1a | ss | 16:55 |
| aelkner | ss? is that kk but different? | 16:56 |
| th1a | No, typing in the wrong window. | 16:56 |
| th1a | OK... so let's say one use case is just syncing activities from the gradebook. | 16:56 |
| th1a | Worksheet popup menu item... | 16:57 |
| aelkner | you're in the gradebook, so by definition, a worksheet | 16:57 |
| th1a | Hm... the problem there is you get into a sync issue. | 16:57 |
| aelkner | and you want to choose an activity (or set of activities) from some worksheet | 16:57 |
| aelkner | and then have them added to the current worksheet? | 16:58 |
| th1a | Well, let's switch gears a bit and think about jelkner's use case a little more specifically. | 16:58 |
| th1a | Because it presents a harder problem actually. | 16:58 |
| aelkner | ok | 16:58 |
| th1a | Because there is the "I've got this predetermined set of activities I want to drop in" issue. | 16:59 |
| th1a | Which is fairly straightforward. | 16:59 |
| aelkner | well, the simple way of looking at it (not necessarily the best way) | 16:59 |
| th1a | But then you have the "I'm going to be adding activities as I go and want them to show up in four different sections issue." | 16:59 |
| aelkner | yes, that too | 17:00 |
| th1a | For the second one, you either need a master/slave relationship between worksheets, | 17:00 |
| th1a | or you say a change to any of these is reflected in all of them. | 17:00 |
| aelkner | yes, that is a tricky case | 17:01 |
| th1a | Hm. | 17:02 |
| th1a | Maybe we should ask jelkner. | 17:02 |
| aelkner | not a bad idea, but i like the outside of the box thinking you have going here | 17:02 |
| aelkner | we could keep on for now and then consult jelkner as well | 17:03 |
| th1a | In the meantime, perhaps you could start with courses. | 17:03 |
| aelkner | can we devide and concur for the moment? | 17:03 |
| aelkner | i see two different types of ideas, on ambitious, on much less so | 17:03 |
| aelkner | 1) the less ambitious: | 17:04 |
| aelkner | we allow users to store sets of worksheets, i.e., IActivities(object) for course and person | 17:04 |
| aelkner | then we allow them to copy either whole worksheets from those sources | 17:04 |
| aelkner | or click on two or five activities from one worksheet source to copy into the current worksheet | 17:05 |
| aelkner | this one is the easiest to conceive of from a data model point of view | 17:05 |
| aelkner | safer, like when we deployed report sheets | 17:05 |
| aelkner | 2) the linked idea you mentioned earlier, interesting but complex | 17:06 |
| aelkner | and i can't say at the moment what issues that would create, but worth thinking about | 17:06 |
| aelkner | but, of course, asking jelkner, too, would help | 17:06 |
| th1a | 1 just doesn't go far enough. | 17:06 |
| th1a | It isn't even worth implementing. | 17:06 |
| aelkner | i see | 17:07 |
| th1a | Or, let me reread it... | 17:07 |
| th1a | OK, we can do this first. | 17:08 |
| th1a | Which is similar... | 17:08 |
| th1a | 1) You've got a worksheet. | 17:08 |
| th1a | 2) You're a school administrator or the leader of the course. | 17:08 |
| th1a | or responsible party if we changed the name. | 17:08 |
| th1a | You can save one or more worksheets to the course (from your gradebook). | 17:09 |
| th1a | And those worksheets appear on all sections of the course. | 17:10 |
| th1a | That would be one-way. | 17:10 |
| th1a | It might update on the fly or not... | 17:10 |
| th1a | Some question kind of. | 17:10 |
| th1a | It doesn't HAVE TO. | 17:11 |
| th1a | I mean, kind of the same question as with the personal version. | 17:11 |
| th1a | The thing is if it is a school-wide template, you've probably figured it out ahead of time. | 17:11 |
| th1a | It is kind of the point. | 17:12 |
| th1a | Compared to the personal sheets, which will almost always change on the fly. | 17:12 |
| aelkner | report sheets are school-wide | 17:12 |
| aelkner | i say that as a reference | 17:12 |
| th1a | Well, true too. | 17:12 |
| th1a | Maybe these are report sheets. | 17:12 |
| aelkner | maybe not though | 17:12 |
| th1a | Course report sheets. | 17:12 |
| aelkner | no limitations in this discussion | 17:13 |
| aelkner | we just need to model well so that changes are easily seen | 17:13 |
| aelkner | and undone for that matter | 17:13 |
| th1a | It is not like I've spent a lot of time thinking about it before hand! | 17:13 |
| aelkner | me, neither :) | 17:13 |
| aelkner | that's why i say, no limitations | 17:13 |
| aelkner | we are just spit-balling here | 17:14 |
| aelkner | and that's why i satered with IActivities(object) because we already have that modeled for section | 17:14 |
| th1a | For courses (school-wide) report sheets make sense since it would also be nice to generate reports. | 17:14 |
| aelkner | we already have that with report sheets | 17:15 |
| aelkner | although deploying a report sheet goes to all sections, all courses | 17:15 |
| th1a | OK, so let's say we're talking about course-level report sheets. | 17:15 |
| aelkner | yes, simple | 17:15 |
| aelkner | from the course contexst, you can go to a view that looks like report sheet templates view | 17:15 |
| aelkner | or the person context, the same | 17:16 |
| aelkner | jelkner did mention a vacation activity that is course independent | 17:16 |
| aelkner | i one is in a course | 17:16 |
| th1a | Well, or perhaps you don't go to report sheet templates at all, and just do it from a teacher gradebook. | 17:16 |
| th1a | It would be a bit more limited. | 17:16 |
| th1a | (not setting score systems) | 17:17 |
| aelkner | could you be specific about the actions in this case | 17:17 |
| aelkner | 1) the user is in a gradebook for a given section | 17:17 |
| aelkner | they hit a link in the left sidebar, entititled? | 17:18 |
| th1a | He is course leader for the relevant course or school admin. | 17:18 |
| th1a | So he sees a "Set as course report sheet" action. | 17:19 |
| th1a | (or whatever) | 17:19 |
| th1a | Clicks that, gets basically a confirmation. | 17:19 |
| th1a | It is copied to the course. | 17:19 |
| th1a | Deployed to current sections. | 17:19 |
| th1a | (and future ones) | 17:20 |
| aelkner | interesting | 17:22 |
| th1a | Do you need to chew on that for a while? | 17:23 |
| aelkner | i'll say :) | 17:23 |
| aelkner | one thing that comes to mind: | 17:24 |
| aelkner | wth report sheets, we have a template container and a deployment step | 17:24 |
| aelkner | the keys of the deployed worksheets have different a nameschooser | 17:24 |
| aelkner | this hels us not have conflicts between user-created and admin-deployed worksheets | 17:25 |
| aelkner | which allow us to reliably deploy/hide | 17:25 |
| aelkner | what you suggested above opens up data model issues | 17:26 |
| aelkner | so i'm not sure what to recommend there at the moment | 17:26 |
| th1a | Isn't it essentially the same problem? Can't we use the same solution? | 17:26 |
| aelkner | perhaps so, i'm not ruling that out | 17:27 |
| aelkner | if we consider IActivities(course or person) to be structured like the report sheet templates container | 17:28 |
| aelkner | and we come up with two new nameschooser patterns to keep things separate | 17:28 |
| aelkner | then perhaps the data model would work out just fine | 17:28 |
| aelkner | and then it's just a matter of where the user clicks and what gets done as a result | 17:29 |
| aelkner | in the lines of what you said earlier about the user being in a gradebook and acting from there | 17:29 |
| aelkner | getting back to the data model behind it, | 17:30 |
| aelkner | in the case of deploying a report sheet | 17:30 |
| aelkner | the template key is guaranteed non-colliding with a user-created worksheet key as said earlier | 17:30 |
| th1a | Is all this because we're too dependent on unique id's? | 17:30 |
| th1a | Also, nobody cares what the id is. | 17:31 |
| th1a | Title has to be meaningful. | 17:31 |
| th1a | ID not. | 17:31 |
| aelkner | ids are always important to a user | 17:32 |
| aelkner | two people (users) can have the same name | 17:32 |
| aelkner | but the username is the key | 17:32 |
| th1a | That's the only place where it matters because you login with it. | 17:32 |
| aelkner | i was just talking with welsh about course ids | 17:32 |
| th1a | That's why courses have different id's for users and the database. | 17:33 |
| aelkner | he made a good point that we erred originally, not making the local course id the key | 17:33 |
| aelkner | i have to agree with that | 17:33 |
| th1a | NO. | 17:33 |
| aelkner | using titles as a key is frought with peril | 17:33 |
| aelkner | a user may wat to reuse a title, but neve a key | 17:33 |
| th1a | If anything, we err in trying to make the keys meaningful at all. | 17:33 |
| aelkner | all databases need a code for reliably retrieving data | 17:33 |
| aelkner | i think you are a bit loose in your thinking here | 17:34 |
| aelkner | once you go about making ids irrelevent, you thought data-reliabilty out the window | 17:34 |
| th1a | I'm only talking about database id's. | 17:34 |
| th1a | Keys. | 17:34 |
| aelkner | but that's the point | 17:34 |
| aelkner | we need to being the user into the key making business | 17:35 |
| th1a | I'm saying, the user never even needs to see that except in the URL. | 17:35 |
| aelkner | if you think about a business (or a school admin office) | 17:35 |
| aelkner | people are always asking each other, 'what's the id of that person, course, resource, whatever' | 17:36 |
| aelkner | having an answer to that question allows people to communicate preictably about a piece of data | 17:36 |
| aelkner | a title never does | 17:36 |
| th1a | And the number they are talking about is probably not the SQL key. | 17:36 |
| th1a | That's what I'm saying. | 17:37 |
| aelkner | it doesn't have to be the SQL key | 17:37 |
| aelkner | but there has to be a use-centric key is all | 17:37 |
| th1a | That's my point. | 17:37 |
| th1a | It isn't the database key though. | 17:37 |
| th1a | That's my point. | 17:37 |
| aelkner | fair enough | 17:37 |
| aelkner | i'm just saying that a data model has to involve the user in the production and maintenace of SOME key | 17:38 |
| th1a | So the namechooser for an id collision doesn't really matter as long as there is no collision. | 17:38 |
| th1a | Well how are you using key? | 17:38 |
| aelkner | something that allows them to KNOW what they are talking about and communicate it ith each other | 17:38 |
| th1a | If you're talking about database id, the user never has to know or care. | 17:38 |
| aelkner | for instance, course id | 17:39 |
| aelkner | that is more important to an admin office than the title is | 17:39 |
| aelkner | the title could change, take the case case of a typo | 17:39 |
| aelkner | who cares what the title is at any given moment | 17:39 |
| aelkner | only the course id makes the course part of a catalog | 17:39 |
| th1a | But there is still no reason to actually use that as the database key. | 17:40 |
| aelkner | sometimes it makes more sense to use the id in question as a database key | 17:40 |
| aelkner | but i agree that is not required | 17:40 |
| aelkner | just more practical from a data model point of view most of the time | 17:41 |
| aelkner | think of courses and sections like products and customer (my business background speaking here) | 17:41 |
| th1a | I don't see how it is more practical... I think it is more just an artifact of how the Zope world tends to do things and the general desire for meaningful URL's. | 17:42 |
| th1a | I don't think anyone in the SQL world would ever imagine having this conversation. | 17:42 |
| th1a | Everything would be identified by a number and that's it (internally). | 17:42 |
| aelkner | i'm not sure it is relavent SQL versos DATA.fs | 17:42 |
| aelkner | the need for keys, ids , urls is the same | 17:42 |
| th1a | I don't think this conversation is going anywhere... | 17:43 |
| aelkner | i think i made my points about data model and users communicating about data | 17:43 |
| aelkner | i don't think that point goes nowhere :) | 17:43 |
| aelkner | and i got to mention the course id issue welsh raised, so that seems relevant to me | 17:45 |
| th1a | He's wrong. | 17:45 |
| aelkner | so i'm wrong, too | 17:45 |
| aelkner | and all that business experience has been a waste :) | 17:45 |
| aelkner | but seriously, i'd be careful about thinking that ids are not important and that we can just user titles somehow | 17:46 |
| th1a | I'm not saying that. | 17:46 |
| th1a | For courses, we have database ids and user ids. | 17:46 |
| aelkner | course ids is what you mean with user ids, right? | 17:47 |
| th1a | The one that is an attribute. | 17:47 |
| th1a | Whatever we call it. | 17:47 |
| aelkner | course_id is an attribute, but it is optional at the moment | 17:47 |
| aelkner | that causes problems for the user | 17:47 |
| th1a | It causes problems if they don't enter a course id? | 17:48 |
| th1a | It could be required. | 17:48 |
| th1a | But probably shouldn't be... | 17:48 |
| th1a | What if kindergarten has no course id in Malawi? | 17:48 |
| aelkner | how do two admin clerks discuss two different courses they are working on? | 17:48 |
| aelkner | by title? i hope not | 17:49 |
| th1a | It will do for kindergarten in Malawi. | 17:49 |
| aelkner | i know that's what you think, but then you ask about a feature, and the question of how to reliable add/retrieve data comes into play | 17:50 |
| aelkner | and the title is not reliable | 17:50 |
| th1a | Neither is course_id if you enter duplicates. | 17:50 |
| th1a | Of course, we have a computer, so we could check. | 17:50 |
| aelkner | that's the point, no duplicates should be alloweed | 17:50 |
| aelkner | right | 17:51 |
| th1a | That's not hard. | 17:51 |
| aelkner | if, for example, the coourse if were the key... | 17:51 |
| aelkner | but i know you are going to nix that | 17:51 |
| aelkner | i'm just saying... | 17:51 |
| aelkner | look at it this way | 17:51 |
| th1a | Wouldn't it be easy enough to check for duplicate course_id or titles? | 17:51 |
| aelkner | think person objects | 17:52 |
| aelkner | the clerk always thinks about username first | 17:52 |
| aelkner | name, maybe the parent calls and says, you misspelled it | 17:53 |
| aelkner | no problem, the clerk doesn't care how it's spelled, only the id | 17:53 |
| aelkner | that is the critical element for them | 17:53 |
| aelkner | the thing that makes discussions of that person meaningful | 17:53 |
| aelkner | and | 17:54 |
| aelkner | any data that is linked to the person shows that id on the form | 17:54 |
| aelkner | again, meaningful to the clerk | 17:54 |
| aelkner | the same could (and in my opinion, should) be considered for course if | 17:54 |
| aelkner | id | 17:54 |
| th1a | I think the main implication of this is that some of our add methods could be doing more checking for duplicates other than database keys. | 17:54 |
| aelkner | that's just a code issue, i'm talking data model and commuicating the meaning of data | 17:55 |
| aelkner | so when a user calls with a bug, the question is, what's the course id | 17:56 |
| aelkner | or username | 17:56 |
| th1a | In essentially every application you use, you never have the slightest idea of what the database key for anything actually is. | 17:56 |
| aelkner | not in my experience | 17:56 |
| th1a | Any id you interact with is another row in the database. | 17:56 |
| aelkner | first, you have user id | 17:56 |
| aelkner | that's the first key you agree with the app on | 17:57 |
| aelkner | then, you create items (products, clients) | 17:57 |
| aelkner | you give them ids | 17:57 |
| th1a | But in the database, the key for your row is probably a number. | 17:57 |
| aelkner | then when you link a product to a customer | 17:57 |
| aelkner | you link the ids | 17:57 |
| th1a | Every book on SQL I've seen uses incremented integers to identify rows. | 17:57 |
| aelkner | that's just the SQL id, not the one that the user communicates | 17:57 |
| th1a | THAT IS MY POINT. | 17:58 |
| th1a | The internal id is meaningless. | 17:58 |
| aelkner | yes, the row number is not interesting | 17:58 |
| th1a | Using an id that is meaningful to the user as the database key is unnecessary. | 17:58 |
| ignas | yes - surrogate ids are meaningless | 17:58 |
| th1a | The user relevant id is a separate attribute. | 17:58 |
| ignas | though even when surrogate id is present, most of the time you have an actual primary key | 17:58 |
| th1a | hi ignas! | 17:59 |
| ignas | that has bussiness meaning | 17:59 |
| ignas | hi :)_ | 17:59 |
| aelkner | yes, hi ignas | 17:59 |
| th1a | Ah... surrogate id. | 17:59 |
| th1a | That's a good term. | 17:59 |
| aelkner | yes | 17:59 |
| aelkner | the primary key is the thing that the user needs | 17:59 |
| aelkner | the thing that they talk about in the admin office | 17:59 |
| th1a | No... | 17:59 |
| aelkner | what's the staud on course A123BQR? | 18:00 |
| aelkner | status | 18:00 |
| aelkner | ah, let me check... | 18:00 |
| aelkner | oh, that one, we need change the title on that one | 18:00 |
| aelkner | ok, good | 18:00 |
| ignas | aelkner, primary key sometimes is just English, by th1a, for first graders | 18:00 |
| th1a | The primary key (glad someone's bringing some proper terminology here) | 18:01 |
| ignas | A123BQR would be considered a surrogate key probably, so it would be more convenient for people and applications to refer to the course :) | 18:01 |
| th1a | The primary key is always unique and identifies the row, correct? | 18:01 |
| ignas | yes | 18:02 |
| th1a | Usually that one is just an incremented integer for simplicity, right? | 18:02 |
| ignas | no | 18:02 |
| aelkner | SQL is not so different from DATA.fs really, the issues are the same | 18:02 |
| ignas | th1a, incremental ids are added next to primary keys most of the time | 18:02 |
| aelkner | the integer id is irrelevant to the user in both cases | 18:03 |
| ignas | th1a, but they are for consistency | 18:03 |
| ignas | yeah, Data.fs most of the time implies a hierarchical key | 18:03 |
| ignas | based on the "location" of the object | 18:03 |
| ignas | so the url of a course is the key :) sans the /sections /groups part | 18:03 |
| aelkner | the heirarchy is mapped into a table by having pairs of keys | 18:05 |
| aelkner | so in SQL a course is unique by having two attributes: | 18:05 |
| ignas | not pairs, I had keys that had 3-4 members in them | 18:05 |
| aelkner | 1) the year id | 18:05 |
| aelkner | 2) the course id | 18:06 |
| ignas | not the id, you can have the year and the course as keys really | 18:06 |
| ignas | you "summarize" them as ids for convenience | 18:06 |
| ignas | 2009, Summer, English | 18:06 |
| ignas | is as good a key as 1, 5, 3 | 18:06 |
| ignas | and you have the term "2009, Summer", the year "2009" and the course "2009, English" | 18:07 |
| ignas | all keyed by the same data | 18:07 |
| ignas | I think I was using these kinds of things as keys in xls export/import | 18:07 |
| ignas | because it was better than trying to come up with unstable surrogate keys | 18:07 |
| ignas | that we don't have in zodb anyway, so can't persist after import | 18:08 |
| ignas | and can't keep stable between 2 exports | 18:08 |
| ignas | though some clients might ask for surrogate keys, we had some cases in a system | 18:08 |
| ignas | that had ids (internal) | 18:09 |
| ignas | and ids that client was entering for every employee | 18:09 |
| ignas | that served as ids for the client | 18:09 |
| ignas | and had uniqueness constraint as well | 18:09 |
| aelkner | it always comes up in those offices... | 18:09 |
| ignas | but that did not mean that we threw our old keys away | 18:09 |
| ignas | we just added a field for this specific function | 18:09 |
| ignas | because if someone can ask you to add it , someone can ask you to remove it or replace it with something else :D | 18:10 |
| aelkner | ignas, thinking flexibly here is not necessarily helpful | 18:11 |
| aelkner | you wouldn't suggest that a user could say, 'we don't need the person username anymore' | 18:11 |
| aelkner | that is set in stone in the app | 18:11 |
| aelkner | we depend on its existence as much as the admin office does | 18:11 |
| ignas | http://c2.com/cgi/wiki?AutoKeysVersusDomainKeys | 18:12 |
| ignas | a lot of text about the issue | 18:12 |
| ignas | yeah, but that's my point, you have a primary key already - username, adding user ids for example, might not make much sense, but if you add user_id (S124576aa for example), should you replace current primary key (username) with the new one | 18:13 |
| ignas | so as to avoid duplicating "functionality"? | 18:13 |
| aelkner | you can't reuse usenames, that's the pojnt | 18:14 |
| ignas | more extreme case is, if you have a term identified by 2009/summer and you add numeric ids for terms, should you remove 2009/summer as the way you use to refer to terms or not? | 18:14 |
| ignas | in sql unique constraint and "key" constraint and "primary key" constraints are different things | 18:15 |
| ignas | sometimes related, but separate | 18:15 |
| th1a | Basically, I think we'd be better off using more surrogate keys. | 18:15 |
| aelkner | what does that mean? | 18:16 |
| ignas | numerical ids for everything! | 18:16 |
| ignas | :) | 18:16 |
| th1a | 2) surrogate key = the system (SQL engine) generates this and the users never see it, it remains internal to the information system. Look at Teradata hashing for example. Another frequent example are _OID columns added by object designers to all the tables. | 18:16 |
| th1a | from http://c2.com/cgi/wiki?AutoKeysVersusDomainKeys | 18:16 |
| aelkner | th1a, we have users | 18:16 |
| aelkner | they are the ones who need top commnicate about data | 18:16 |
| th1a | The users see other id's. | 18:17 |
| aelkner | and those ids are the important ones | 18:17 |
| aelkner | they need to be unique | 18:17 |
| th1a | That can be enforced in code. | 18:17 |
| aelkner | they need to reliable correspond to data that they see | 18:17 |
| aelkner | the data needs to be searchab;le by those ids | 18:17 |
| th1a | Also, a situation where all the data is there, but slightly duplicated and out of sync is not the worst case. | 18:18 |
| th1a | But yes, you can have other attributes (course_id) which are unique, searchable, etc. | 18:18 |
| ignas | in some places we are using ids by the way | 18:19 |
| ignas | i think all the things that are catalogued | 18:19 |
| ignas | and indexed | 18:19 |
| ignas | have intids | 18:19 |
| ignas | they are not very nice | 18:19 |
| ignas | but they do exist in schooltool already | 18:19 |
| aelkner | right, the user knows nothing about those | 18:19 |
| ignas | they might be very big numbers though :) | 18:19 |
| aelkner | so they are more hostile than helpful | 18:19 |
| ignas | veeeeery big :) | 18:19 |
| th1a | They only see them in urls. | 18:20 |
| aelkner | a nasty part of the data model in y opinion | 18:20 |
| ignas | but you can use those ids to instantly retrieve an object from zodb | 18:20 |
| aelkner | that just creates developer work rather than solving a user problem | 18:20 |
| aelkner | the key is to model the data so that a user can codify and retrieve data | 18:21 |
| aelkner | the internal storage is not relevant | 18:21 |
| aelkner | and taking advantage of the user's need to codify data when coding the app is helpful | 18:22 |
| aelkner | killing two birds with one stone so to speak | 18:23 |
| aelkner | think person usernames, also the key | 18:23 |
| aelkner | year ids (not titles), also the key | 18:23 |
| aelkner | IntIds, yuck, overly-complex workarond of a simple problem | 18:23 |
| aelkner | better to think of the data from the point of view of the user's need to codify | 18:24 |
| aelkner | and code in step with that | 18:24 |
| th1a | Well, I wouldn't care if it seemed simple. | 18:24 |
| th1a | You start off saying things like this aelkner: | 18:24 |
| th1a | one thing that comes to mind: | 18:24 |
| th1a | wth report sheets, we have a template container and a deployment step | 18:24 |
| th1a | the keys of the deployed worksheets have different a nameschooser | 18:24 |
| th1a | this hels us not have conflicts between user-created and admin-deployed worksheets | 18:24 |
| th1a | which allow us to reliably deploy/hide | 18:24 |
| th1a | what you suggested above opens up data model issues | 18:24 |
| th1a | so i'm not sure what to recommend there at the moment | 18:25 |
| aelkner | yes, i did say that :) | 18:25 |
| aelkner | your point? | 18:25 |
| th1a | Well, that makes it sound like your approach is not easy. | 18:25 |
| th1a | Especially when you use the phrase "data model issues" which suggests a fundamental conceptual flaw. | 18:26 |
| aelkner | well, in the case of report sheet templates, i started from the data model we had at the time | 18:26 |
| th1a | So perhaps you should just use less dramatic phrasing. | 18:26 |
| aelkner | and that model did not include ids for things | 18:26 |
| aelkner | when i say 'data model issues' i mean the whole set of actions | 18:26 |
| aelkner | that bring up the need to codify for the user's benefit | 18:27 |
| aelkner | now, in the case of report sheet deployment | 18:27 |
| aelkner | for now, we have these templates that have no id that is meaningful to the user | 18:27 |
| aelkner | and the titles can be duplicate, for that matter | 18:27 |
| aelkner | but once we got to deployment | 18:28 |
| aelkner | we had to decide that titles were unique | 18:28 |
| aelkner | you made that decision recently, adn it was necessary | 18:28 |
| aelkner | as you saw once we wanted to be able to hide | 18:28 |
| aelkner | and unhide for that matter | 18:29 |
| aelkner | then, the title became the unique user key | 18:29 |
| aelkner | for now, it works reliably | 18:30 |
| aelkner | but, i could see a user in the future complaining about the lack of control over that | 18:30 |
| aelkner | really, the best model would have the user choose an id for the template | 18:30 |
| aelkner | then id they wanted to, they could have two template withe the same title | 18:31 |
| th1a | OK, I we've hit the 2 hour time limit. | 18:31 |
| th1a | We could just give the template an id. | 18:31 |
| th1a | We don't need to make them think of one. | 18:32 |
| aelkner | well, i'm not going to start anything after the two hour limit :) | 18:32 |
| aelkner | but i just don't agree that the user should be spared the codify step | 18:32 |
| th1a | In conclusion, aelkner is banned from using the phrase "data model issues" | 18:33 |
| aelkner | because it serves them more than hasstles them | 18:33 |
| th1a | OK, let me know what you come up with in the next day or so aelkner. | 18:33 |
| th1a | See you guys on Wednesday. | 18:33 |
| th1a | Take care ignas! | 18:34 |
| aelkner | i'll talk to jelkner | 18:34 |
| * th1a drops the bag of gravel. | 18:34 | |
| ignas | th1a, bye | 18:34 |
| aelkner | thanks for you input ignas | 18:34 |
| aelkner | good to hear form you | 18:34 |
| ignas | always glad to be useful :) | 18:34 |
| th1a | replaceafill maintains a diplomatic distance... | 18:34 |
| replaceafill | :D | 18:34 |
| replaceafill | i've been reading the whole thing ;) | 18:35 |
| th1a | That's what happens when you grow up in a country with death squads. | 18:35 |
| replaceafill | hey! come on! | 18:35 |
| replaceafill | :P | 18:35 |
| aelkner | ooh | 18:35 |
| th1a | You learn a certain prudence. | 18:35 |
| th1a | Or at least I'd hope. | 18:36 |
| *** ignas has quit IRC | 19:43 | |
| *** replaceafill has quit IRC | 20:53 | |
| *** replaceafill has joined #schooltool | 22:07 | |
| *** maker-kun has joined #schooltool | 23:42 | |
| maker-kun | Hello. I am trying to build schooltool from scratch, but I have a problem with zope when running $ make run | 23:48 |
| maker-kun | http://bpaste.net/show/20730/ | 23:48 |
| maker-kun | Seems like on the irc logs you had to face something similar in the previous years, but I didn't find any useful information there. | 23:49 |
| replaceafill | maker-kun, did you branch from launchpad? | 23:50 |
| replaceafill | or did you download a compressed file? | 23:50 |
| maker-kun | replaceafill: from lauchpad | 23:54 |
| maker-kun | merged about one hour ago. | 23:54 |
| maker-kun | Ah, replaceafill, I am on osx. | 23:54 |
| replaceafill | lp:schooltool? | 23:55 |
| maker-kun | $ bzr merge | 23:55 |
| maker-kun | Merging from remembered parent location http://source.schooltool.org/var/local/bzr/schooltool/schooltool/trunk/ | 23:55 |
| replaceafill | ah ok | 23:55 |
| replaceafill | let me try in python2.5 | 23:55 |
| * replaceafill is not sure if trunk runs on python2.5 | 23:56 | |
| maker-kun | replaceafill: I have also 2.6 and 2.7 installed on this machine. | 23:56 |
| replaceafill | can you try 2.6? | 23:57 |
| maker-kun | Is python_bootstrap enough to set python version? | 23:57 |
| replaceafill | edit Makefile | 23:57 |
| replaceafill | PYTHON=python | 23:57 |
| replaceafill | change it to PYTHON=python2.6 | 23:57 |
| replaceafill | if osx calls it that :) | 23:57 |
| * replaceafill has no experience on osx, sorry | 23:57 | |
| maker-kun | http://bpaste.net/show/20731/ | 23:58 |
| maker-kun | uh, let's try that | 23:58 |
| maker-kun | Same error :\ | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!