Posts

Showing posts from July, 2010

unsuccessful programmer is unsuccessful

Quick update, I'm still working on the authentication. I have most of the ground work in place however I'm currently have a character encoding issue. Apparently somewhere the hashed password in the database is getting mutated into something different. Basically it doesn't match the hash fresh from the user so the authentication fails. It doesn't throw exceptions all over anymore so that is pretty neat. But that's what happens when you work so long on a piece of code before to get far enough to actually be able to test something. *Lol irreducible complexity* At any rate the generic data access components are tested now and they are working great. I think the nature of the issue is that the editor I'm using for SQLite is using a different character encoding than I'm using from code. Thus a hash password I enter via the editor doesn't work at all. So in the end I may end up adding the ability to register users just so I can test logging in.

Another thing t…

One function to rule them all

I finish the initial implementation of the function that will process database command objects for SQLite databases.It is large somewhat complex and untested so I thought I would share.

DatabaseResultSet Execute(DatabaseCommand& databaseCommand)
{
DatabaseResultSet databaseResultSet;

const char* tail=NULL;
sqlite3_stmt* statement=NULL;
size_t row=0;

rc = sqlite3_prepare_v2(
mDatabase, /* Database handle */
databaseCommand.GetQuery().c_str(), /* SQL statement, UTF-8 encoded */
databaseCommand.GetQuery().length(),/* Maximum length of zSql in bytes. */
&statement, /* OUT: Statement handle */
&tail /* OUT: Pointer to unused portion of zSql */
);
if(rc!=SQLITE_OK)
{
return databaseResultSet; //no need to call finalize because prepare faile…

If it builds ship it.

First of all I'll explain the reason for the title. I'm in the process of committing changes to the trunk that I have no reason to believe work. In all fairness it is data access code that isn't being called yet so it shouldn't break anything. However because I have put a pretty good amount of work into it I don't want it to be lost if my computer bites the dust.

Second bit of news I have made a change to the way I plan to handle the data access layer. From now on the data access will have two classes for each database. The wrapper class and the actual data access class. Having a wrapper class that deals with a single connection allows you to safely deal with the connection and execute commands without making the actual data access class super messy. Now the PostgreSQL data access is already super messy and I may or may not do some cleanup in the near future. I do plan to do the cleanup though I just don't know if I want to do it right now. At any rate the new c…

Data Access Layer

First of all apparently the value of a data access layer is in question. In my opinion if your using a database you should use a data access layer. Because for one things will change and having a single point to make those changes is truly priceless. Well priceless to the programmer. Anyway if your database scheme changes or even worse if you have to port to another database you will wish you had a data access layer if you don't already.

So enough of that little rant on to business well sorta. I have been working on the database related functionality. I started this release thinking it wouldn't be a big deal but I'm quite aware that this should have probably been broken up into at least a couple releases if not more. But anyway I still don't have enough database code to make item testing work.

In the course of working on the database code I realized a severe problem with implementing the PostgreSQL database functionality. That being that users will not be able to test th…