 |
.. (לתיקייה המכילה) | |
Why can't we create the table user? | |
|
Appearently user is a reserved word of SQL and PostgreSQL therefore it can't be used (or atleast not in a simple way). Use instead the table users. This is how we will define this table in your account. |
Do we need to use rollback or commit? | |
|
No. Please don't use rollback or commit. As I mentioned in the tutorial, PostgreSQL's behaviour with commit/rollback is different from the standard. I didn't teach you how to use it and I don't want you to use it. You don't need rollback/commit in order to solve this exercise. Assume that any statement you send to PostgreSQL is followed by a commit statement. |
What to do after having an unexpected error | |
|
In the exercise description we told you to write error message to the stderr. In addition to that I want to add: 1. The message is not defined. You can write any suitable message. 2. After writing the error message exit the program (After closing the connection). 3. I stress again that when ever you are asked to write EMTPY or ILL_PARAMS it is an expected error and you should write EMPTY or ILL_PARAMS to the standard output and continue with the program. Unexpected errors are for example problem to connect to the database. |
האם מותר ליצור מבטים בזמן ריצה? | |
| כן, ניתן ליצור מבטים בזמן ריצת התוכנית. יש לזכור למחוק אותם בסוף. |
How to work with the date type? | |
|
use DATE('2001-11-21') in your query for example: SELECT title FROM Accepted WHERE adate<DATE('2008-07-25'); |
we need to compare two dates. how should we do it? | |
|
SELECT DATE('2008-11-01')-DATE('2008-12-21) as val and check whether val is positive or negative. |
In the command addViewed, can we add a view of an article when the date of the view is earlier than any accepted version of the article. | |
|
No, you can't. You should print ILL_PARAMS and exit. You can add a view of an article only if that article has an accepted version from earlier date than the view. |
Should we print ILL_PARAMS in case we get "addLink title1 title2" and the record (title1,title2) already exists in the link table? | |
|
No, you shouldn't print ILL_PARAMS. You should do nothing. The key of the table links is fromTitle and toTitle so it mustn't have the same record twice. Therefore if you get a request to add the same record again you mustn't add a record. What to do in that case is a matter of definition. In your case we define you to do nothing. This link already exist, no need to add anything. The same is true for addViewed. If you are asked to add view which already exists in the table view (<id>, <title> and <date>) do nothing. |
In removeUser in case of change should we print ILL_PARAMS in case the user newId does not exist? | |
|
yes. You should print ILL_PARAMS and exit without changing or deleting anything. |
In the command deleteUser when the command fails (because one of the reasons given in the exercise's description) we need to print ILL_PARAMS and exit. | |
|
You should print ILL_PARAMS and do nothing more (No deleting and no changing anything) You should treat the command as an atomic command which means that it either fully succeeds (Changing and/or deleting what you need and no ILL_PARAMS) or fully fails (No change at all in the database) |
In popularVersions, assuming the average is 5 what should be <aboveAvg> in order to present all the articles with more than 5 views. | |
| It should be 0. If you want to present the articles with more than 10 views then you should ask for 100% more than the average etc. |
In hostile function we must print the id of the hostile editor ONLY if he sabotaged ALL versions of our editor? | |
| Yes. |
מה קורה אם יש שתי גרסאות פופלריות בדיוק באותה מידה (והן הכי פופולריות עבור הערך הזה)? | |
|
יש להציג את כולם. כלומר להציג רשומה עבור כל אחד מהגרסאות הכי פופולריות. |
In addAccepted we need to check that a version for <title> exists in the date <vdate>. | |
|
In addAccepted you need to check that the given version exists in the database. The version is recognized uniquely by editor,title and date (which are the key for the table Version). Therefore you need to check whether a version for <title> exists in the date <vdate> and was written by <eid>. (In the exercise's description we accidently omitted the <eid>) The same is true when checking whether that version already has an accepted version. (You need to check whether accepted table contains record with <eid>, <title> and <vdate;>) |
In addVersion, what should we do if we are asked to add version which already exists in the Version table (the same <id>, <date> and <title>)? | |
|
id, date and title are the key of the table Version and therefore they can't exist twice in the table. In that case you also have the <content> which may be different. We don't want you to change this record but you can't just do nothing (As we told you to in addLink and addViewed) because that will be ignoring the command. Therefore in this case you will have to print ILL_PARAMS and exit. |
In hostileEditors what to do if two editors created a version for the same article at the same date. | |
|
In order to solve this rare case and other similar cases we will assume from now on that there can't be more than one version for the same article at the same date. This should be checked in addVersion however we will not check it and you don't need to implement it. |
In hostileEditor can an editor. If an editor created a second version immediatly after the first one, does that mean he can't have hostileEditor? | |
|
No. He can have an hostileEditor. We said that hostileEditor must be the first one to change the editor's version. However we don't include the editor itself in that calculation. Furthermore, if editor A had a version on 2008-01-01 and another one (for the same article) on 2008-01-03 and editor B had a version for the same article on 2008-05 then B is hostileEditor to A. (Assuming any other versions of A are also reedited by B like that) |
When you ask to write null, do you mean to leave it empty or to write "null"? | |
|
We mean to write "null". The exception is null in the field of popularity. Since the macro POPULAR_VERSIONS_REC expects integer, write -1 istead of null (don't write 0) |
When sorting by field with nulls, where to put the records with the nulls? | |
| Since PostgreSQL put the records with null at the end you should do that as well. |
When calculating hostileEditor does 7 days include the 7th day or not? | |
| if (date1 - date2 < 7) then it's ok. |
Can you please fill the holes in the popularVersions definition? | |
|
Few holes to feel: 1. Between the given dates includes the dates themselves 2. When aboveAvg is omitted print all the results. 3. The results of popularVersions will be ordered by popularity and then by title (not only by popularity as was written in the exercise's description) 4. Notice that versions without approved versions in the given dates obviously also don't have views at that time. But their popularity is null (-1) and not 0. 5. Average popularity is calculated over the popularity of articles (not the popularity of versions) and therefore takes in consideration all the articles with normal poplarity and also the articles without any views (poplarity 0) but doesn't take in consideration articles who have null (-1) popularity. |
Do we need to add \n after ILL_PARAMS and EMPTY | |
| yes |
In popularVersion when we calculate the average popularity. If there are articles with more than one version (more than one version with the highest popularity for that article), how should we calculate them in the average. | |
|
You calculate each article once. For example: Article A have version AA with popularity 53% and version BB with popularity 53%. Article B have version CC with popularity 23%. The average popularity will be (53 + 23)/2 = 38%. Given aboveAvg = 0 you will print two records: article A with version AA and 53% and article A with version BB and 53%. |
In addAccepted you said in the exercise's description (page 1) that there can't be more than one accepted version at the same date for the same article. | |
|
This should be checked. However, since we haven't mentioned that case till now we won't ask you to implement it and we won't check it. Still, you can rely on the integrity of the database in that matter. |
What does exactly PQclear does? | |
|
PQclear frees the storage associated with the PGresult. Whenever a query result is no longer needed, free it with PQclear. You can keep a PGresult object around for as long as you need it; it does not go away when you issue a new query or if you close the connection. To free it, you must call PQclear. Failure to do this will result in memory leaks in the frontend application. | |
| קישור: Link: Ссылка: وصلة: | http://www.redhat.com/docs/manuals/database/RHDB-2.0-Manual/prog/libpq-exec.html |
In popularVersions when sorting by popularity and there are articles with popularity null (-1) should we put them at the begining like -1 or at the end like null. | |
|
The use of -1 is only in order to recognize the field as null, therefore you need to sort it as null and not as -1. You need to put those articles with popularity null at the end of the records. |
How to calculate the average popularity? | |
|
I quote here what was wriiten under "Can you please fill the holes in the popularVersions definition?" section 5: "Average popularity is calculated over the popularity of articles (not the popularity of versions) and therefore takes in consideration all the articles with normal poplarity and also the articles without any views (poplarity 0) but doesn't take in consideration articles who have null (-1) popularity." Nothing changed still then. To those of you who still don't understand: the popularity of an article is the higest of its versions popularity. You need to average on those values and not over the popularity of all the versions. |