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 the client and server without installing PostgreSQL and setting up the tables and such. Although not a problem for a server install I don't expect any passers by to put that much effort in to playing with alpha stage software. So here is my solution. I'm going to implement the database functionality using SQLite at first with the ability to complete the PostgreSQL implementation without allot of extra work.

Now all that sounds fine well and good but I need to make several data structures for dealing with database stuff in a generic fashion. For example I need a command object as well as probably a data table and a parameter object. The reason is that I need to contain and pass this information around in a standardized way otherwise the repeat effort on the data access layer is gonna get out of control quickly. One of the reason for the problems is the that the libraries use parameters in different ways. Both of the APIs I have used provide some way to handle parameters in a secure way but syntax wise they are worlds apart. So with those extra data structures I can abstract that different and make the data access layers for each database allot more uniform. The more code I can share between the data access layers the better.

So in short I'm stalled on the items until I have the database stuff working. once I have that working I will be able to give characters items and test that they equip & appear in a characters inventory. right now I would have to do that from code and that may open another can of worms because so far hard coding stuff works for a little while but later it comes back to bite you sometimes. This is one case where I don't want to have that risk because we are all after all talking about data integrity. Adding persistence to the game world in even a limited sense will be a huge step forward as well.

One final piece of news I have moved the milestones around in terms of required functionality for each release. Because I decide effective testing of items requires the database to be working 0.9.0 is not real authentication. This milestone was much later but I have moved it ahead of items. Along with that I have moved guild and character persistence after real authentication. So in short all of you have to wait three more releases for items. However you will get a release sooner now because these steps were required anyway but now I will reach the milestones in order so no releases will get skipped.

One little bonus I added a "/commands" command that works just like "/help command" and I have moved the in game browser urls out of code and into the url.cfg file. So any of you looking to actually use this thing to make a game now you don't have to worry about hard coded urls. Alright that does it for tonight thanks for reading.


Popular posts from this blog

VK9 - Milestone8 Completed

VK9 - Milestone13 Completed

VK9 - Milestone16 Completed