| Date | Action |
| Back in September... |
|
| October, before 10/17... | Installed PostgreSQL on my computer. Started playing around with creating databases. Downloaded manuals in pdf format (admin, programmer, tutorial, user) |
| October 17 | Printed out programmer manual. Found an example for how to connect to a PostgreSQL database that is written in C. Since I can't find my Programming Perl Book, I might as well do in C. I sure need the review. |
| October 18 | Hacked testlibpq.c. testlibpq.c is a sample program from the programmer maunal for PostgreSql that connects to the database template1, retrieves the content from pg_database, the system catalog, and prints the results. Thanks to Charlie, I was able to compile and link it with the Postgres libraries. I would later discover this program had a bug in it. |
| October 19 | Hacked testlibpq2.c. testlibpq2.c is another sample program the programmer manual that does asynchronous notifying. I was able to sucessfully compile, link, and run this program. I tried hacking testlibpq3.c, which does retrieves the data using a binary cursor. However, I could not get it to compile becuse there is a bug in one of the libraries it needs. Not sure about how to fix it. It may be useful since it does define POLYGONS. We'll see. I then proceeded to hack testconnect.c, which is based on testlibpq.c. Initially, the program connected to mydb, my personal database :), retrives the data from TBL1 (table 1) and prints the contents of the table. When I ran it, I kept getting the error, " PQfname: ERROR! field number 1 is out of range 0..0 (NULL)." That's when I discovered I had typed a wrong function call (typeo). It was the same mistake I had made in testlibpq.c. After I made the corrections, both programs worked great. I then proceeded to modify testconnect.c so that it first inserted a new value into a table and then print the contents of the table. It worked. There is at least one issue regarding my implementation. I used PQexec, which takes as arguements a pointer to a connection, and a pointer to the SQL command (a string). This function sends the SQL command and awaits the result. This is fine for a small system with few users, but does not scale well. I've read in the programmer manual that PQsendQuery is more efficient. It takes the same arguements as PQexec and serves the same function, except it does not wait for a result. Thus, application is not tied down waiting for results. Using PQsendQuery means that a different method of result checking must be used. For simplicity, I will use PQexec. Later, I will modify the code to use PQsendQuery. |
| October 24 | Made changes to testconnect.c and called it dbman (as in DB manager). I added the ability to accept command line argument. My thought was I should have just one program handle all of the database transactions rather than having several different programs for each conceivable command. What I don't know yet is how I am going to pass the results back to the client program. I don't even know what data the client programs want! Next step will be figuring out what options I should have the program accept. |
| October 27 | Modified testconnect.c to accept command line arguments. The values of the arguments are passed to sprintf which generates the string that is used as the second argument for the PQexec function. I'm trying to meet with Cam and Alex so that we can determine the program interfaces. After talking with Charlie last Monday and thinking some more, I think one program that handles requests from the algorithm (i.e. for user authentication) and another program that will handle requests from the admin front end will be better that just a general program to handle all requests. There will be a third piece of software that only the system superuser will be able to use that will allow the system supersuser to perform maintenance on the system. |
| November 26 | Over Vacation, I have been working on little bits and pieces of test code, but nothing worth writing home about, until today. I sucessfully compiled and ran adduser.c which adds a user to the now ss99 database. I changed the data definition a little bit to make testing easier. I have not added any of the constraints yet. I plan to do that tomorrow. Right now, there are seven attributes - user_id, lastname, firstname, begin_time, end_time, characteristics, and thumbprint. characteristics will be an single dimension array of various characteristics of the user's thumbprint. thumbprint is the actual image of the user's thumb. It will be stored as an 2 dimensional array of greyscale values(integers). both characteristics and thumbprint are not null to make testing easier. Later the not null contraint may be added. |
| December 5, 1999 | I know that from the lack of entries, it would appear that I have not been getting much work done. While that is partial true, the real story is that for the last week, I have been struggling with my adduser program and segmentation faults. Time is running short, but I'm making headway. If I work hard for the next few days, then I am fairly confident I can finish all of the code before the 13th. I cleared a major hurdle today. For the longest time, I kept on getting segmentation faults whenever I was running adduser.c. I could not figure it out, and I not sure I ever will, which is probably not the best thing, why I kept on getting segmentation faults. Now, thanks to a major breakthrough, my code works. The break though was allocating a static char array of 126 bytes and passing that as an argument to build_string (see code). Before I would only pass to build_string the filename of the datafile, build the string in the function, then pass back a pointer to it. I think what happens when I do this is that because the string is so long, it ends up overwritting other vital data in those memory locations. I think that might explain why I would run into problems with not being able to close the datafile, for example. Because the string is so long, it overwrites the file pointer. Result: Segmentation fault Now that this works, its onwards from here. The next task is to write the delete user program. I think modify user should use delete user to wipe out the current user data and then enter the new data. Of course, any data that will not be modified will be preserved before wiping out the user data in the table. More specifics to come later. Verify user data will simply check if the user data is correct and that the system can recognize a user's thumbprint. If the user data is wrong, the there will be an option to modify the user data. Again, more to come later (which will be soon). |
| December 6, 1999 | Wrote deluser.c and got it to work. Next step is to combine adduser.c and deluser.c to create moduser.c. After that, create chkuser.c. Finally, I need getuser.c, which will get user data from the database and the superuser application that will glue together adduser.c, deluser.c, moduser.c, and chkuser.c. |