logo logo

 Back to main page

The NWNX Community Forum

 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
COMMIT, Integer Ranges, and Rows/Character Questions

 
Post new topic   Reply to topic    nwnx.org Forum Index -> Database related
View previous topic :: View next topic  
Author Message
RansomStark



Joined: 25 Feb 2005
Posts: 5

PostPosted: Sat Feb 26, 2005 22:43    Post subject: COMMIT, Integer Ranges, and Rows/Character Questions Reply with quote

I have three questions after some time today playing with this:

1. SQLite COMMIT

I'm using the SQLite along with SQLiteCC to peek at my database. I scheduled a commit to happen in the onload script after 1 minute, and the function it calls schedules itself for another commit after 1 minute. In this way I think I have a periodic database commit call for the life of the module.
Fine.
But when I look at my database with SQLitecc, it reports that the gold I've deposited into the DB is what it should have been after a commit. As in, it sees the updated value in the field before the commit occurs. Is this an invalid test? Do I have to pull the power or perhaps kill the server task for a real test of whether or not the commit is necessary and working?

2. Integer ranges -> Database representations

In the asp implementation of the database, they chose to represent everything as a string. In NWN, an integer is 65k to -65K (i think). I'm trying to implement a simple banking system. How do I get around the small integer limit, and how is the asp implementation intended to work with large integers turned strings? I'm a little confused on how this is all supposed to work. A DB int is quite a bit larger than an NWN int, ... I'd like to use the DB ints, I think... not sure. Thoughts?

3. Mutliple rows for 1 Character

In the asp demo module, the implementation for the example table is setup so that for every variable a character has assigned to them, there is another row in the pwdata table. Is there a good reason for this? It strikes me that you would want to have one row for each character and have fields for each variable that might be assigned to them.

One reason I can think of is that it's easier for developers to add new variables to a character. But this comes at a huge cost of having the DB iterate over many many more rows in the database, not to mention returning a set instead of a row....

Thoughts?
Back to top
View user's profile Send private message
NoMercy



Joined: 03 Jan 2005
Posts: 123
Location: UK

PostPosted: Sun Feb 27, 2005 0:26    Post subject: Reply with quote

After you COMMIT, you should also be issing another BEGIN to start a new transaction, if you don't youre essentially going back to write to disk after every SQL statement.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
RansomStark



Joined: 25 Feb 2005
Posts: 5

PostPosted: Sun Feb 27, 2005 0:47    Post subject: Reply with quote

So... something like this?

Code:

void SQLCommit()
{
    SQLExecDirect("COMMIT TRANSACTION");
    SQLExecDirect("BEGIN TRANSACTION");

    //Schedule next commit "interrupt"
    DelayCommand(SQL_COMMIT_PERIOD, SQLCommit());
}
Back to top
View user's profile Send private message
NoMercy



Joined: 03 Jan 2005
Posts: 123
Location: UK

PostPosted: Sun Feb 27, 2005 15:05    Post subject: Reply with quote

You don't need the TRANSACTION part on the end of BEGIN and COMMIT, otherwise it looks fine.

If you want details the TRANSACTION sqlite ignores it (used for mutiple concurrent transactions, which sqlite doesn't do), and I'm not sure if MySQL likes it, since it's 'BEGIN' is a alias to START TRANSACTION, so probably good to stick with just 'BEGIN' and 'COMMIT' if you might want to change database at some point.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Papillon
x-man


Joined: 28 Dec 2004
Posts: 1060
Location: Germany

PostPosted: Sat Mar 05, 2005 13:26    Post subject: Re: COMMIT, Integer Ranges, and Rows/Character Questions Reply with quote

RansomStark wrote:

2. Integer ranges -> Database representations

In the asp implementation of the database, they chose to represent everything as a string. In NWN, an integer is 65k to -65K (i think). I'm trying to implement a simple banking system. How do I get around the small integer limit, and how is the asp implementation intended to work with large integers turned strings? I'm a little confused on how this is all supposed to work. A DB int is quite a bit larger than an NWN int, ... I'd like to use the DB ints, I think... not sure. Thoughts?


What do you mean with "asp implementation" ? An integer in NWN is far larger than an integer in C, btw, so there is no 65K limit. Check out the NWN lexicon on how big an integer can actually be.

Quote:

3. Mutliple rows for 1 Character

In the asp demo module, the implementation for the example table is setup so that for every variable a character has assigned to them, there is another row in the pwdata table. Is there a good reason for this? It strikes me that you would want to have one row for each character and have fields for each variable that might be assigned to them.

One reason I can think of is that it's easier for developers to add new variables to a character. But this comes at a huge cost of having the DB iterate over many many more rows in the database, not to mention returning a set instead of a row....


You could store everything in a single row, but I would not recommend it. The main reason is that you will need only 2-3 variables at a time, and not the whole data set of the player in a given script. Second, the cost of iterating over a set is smaller than selecting columns individually from a single row.
_________________
Papillon
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
RansomStark



Joined: 25 Feb 2005
Posts: 5

PostPosted: Mon Mar 07, 2005 19:52    Post subject: Re: COMMIT, Integer Ranges, and Rows/Character Questions Reply with quote

Papillon wrote:
RansomStark wrote:

2. Integer ranges -> Database representations

In the asp implementation of the database, they chose to represent everything as a string. In NWN, an integer is 65k to -65K (i think). I'm trying to implement a simple banking system. How do I get around the small integer limit, and how is the asp implementation intended to work with large integers turned strings? I'm a little confused on how this is all supposed to work. A DB int is quite a bit larger than an NWN int, ... I'd like to use the DB ints, I think... not sure. Thoughts?


What do you mean with "asp implementation" ? An integer in NWN is far larger than an integer in C, btw, so there is no 65K limit. Check out the NWN lexicon on how big an integer can actually be.


I meant the asp_demo_module and asp_include implementations of the DB store and DB read functions that come with the plugin. It converts everything to strings I think before it stores them in the database, as strings. Just wondered why.

-edit-: Oh maybe it's aps, not asp, I'm at work and can't double-check

And as for Int sizes, heh, I didn't check the lexicon myself, I just asked a friend and apparently he gave me bad information.


Papillon wrote:
RansomStark wrote:

3. Mutliple rows for 1 Character

In the asp demo module, the implementation for the example table is setup so that for every variable a character has assigned to them, there is another row in the pwdata table. Is there a good reason for this? It strikes me that you would want to have one row for each character and have fields for each variable that might be assigned to them.

One reason I can think of is that it's easier for developers to add new variables to a character. But this comes at a huge cost of having the DB iterate over many many more rows in the database, not to mention returning a set instead of a row....


You could store everything in a single row, but I would not recommend it. The main reason is that you will need only 2-3 variables at a time, and not the whole data set of the player in a given script. Second, the cost of iterating over a set is smaller than selecting columns individually from a single row.


Fair enough, it's been a while since I designed a DB, so thanks for the help.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    nwnx.org Forum Index -> Database related All times are GMT + 2 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group