Database Scripts and a data file fix.

[Greg-Donaldson]

dataSnag.py is meant for pulling data from files. Right now its written with the idea of just pulling out comma-separated info from one of the .dat files.

database_creation.py is my first attempt at a script to create a database on load-up for use in Freedom. Right now it just works for planets, but the rest can be done fairly easily (using my work here as a template).

planet.dat: I noticed an error on one of the planets. Ownex was missing the number of environs. I checked the map, and updated it with the proper number.

[Greg-Donaldson]

That's the weird thing. The sloyalty and aloyalty variables are a part of the data file. As far as which is needed... I have no idea.

And won't we need a database for the star system game?

[hallister]

The data files won't need to be loaded into the database until after a scenario is chosen, and since each scenario dictates whether aloyalty or sloyalty is chosen, we only need one "loyalty" for any given game itself.

[Greg-Donaldson]

Huh. I had always thought we were going to load up the database with all the .dat files before the scenario was chosen, then, from the scenario that was chosen, data could be pulled from the database depending on what you needed (it seemed easier to code in this way). I'll keep plugging away at it.

[mein1156]

@Greg-Donaldson Hey greg, good work on going through this stuff. How are you testing to make sure you pulled and stored the right data? I think we could turn however you are doing this stuff into a good unit test and document it for our testing.

[Greg-Donaldson]

If you go down to the bottom there is a command that I have commented out. That command goes into the database and pulls the info in the selected table out (as a Tuple, I think). Changing the name between brackets (like changing [Planets] to [Possessions]) will change what table you pull out.

As a note, the strings are done in unicode, so if you see a u before the stuff you want to see, that is supposed to be there.

...I think.

[mein1156]

@Greg-Donaldson How are constraints, such as foreign and primary keys going to be incorporated? I noticed you had owner as a String. Are we planning on sometime turning that to a foreign constraint on the character table?

[mein1156]

@Greg-Donaldson I'm confused on one point, I thought Andy was in charge of the ORM and therefore the database scheme. How does your scheme fit with Andy's, or am I thinking about this wrong?

[Greg-Donaldson]

@mein1156 I wasn't planning on using foreign keys for the database. It can be done, but the added level of complexity of using a foreign key isn't something that I want to use, as it might be confusing for anyone not familiar with databases and using databases.

As for Andy's database scheme... I have not seen it. So, I can't really answer your question.

[Greg-Donaldson]

Pretty significant update all around.

[mein1156]

@Greg-Donaldson Don't worry about using foreign keys, as far as I know, only two people will be doing database stuff directly, the rest will be using the interface or something, if that is really the plan. I could be totally wrong. In the end, I think we will have two choices when testing comes, either will have to do more testing to make sure that the good values are receive etc or add more constraints such as foreign keys. I don't know, I think in the end, foreign keys would be a big help for us testers.

[Greg-Donaldson]

Possibly. If we need to implement it, it can be implemented.

[mein1156]

Ok. Keep on going :).

[CrockAgile]

@Greg-Donaldson is there anyway to move the definitions of the classes outside of the loadDatabase function? The example you gave uses direct SQL statement execution, which does work, but does not take advantage of ORM. For example my previous code would be something like this:

myCharacter = session.query(Character).filter_by(name = "Some Guy").one()

Which would create myCharacter as an instance of the class 'Character' with the values found in the table assigned to that class under tablename .

This approach is very convenient as it allows manipulation of it just as an object, and then just updates the database with a single session.commit() , as opposed to what could be dozens of SQL update requests. It also allows for rollbacks in case of corruption.

We can chat about it more in class tomorrow I bet, see ya then

[mein1156]

@crockj72 You should talk to @andschwa, he is building the ORM.

[CrockAgile]

Actually already sorted the issue, although I bet @andschwa will want to clean it up a bit, I moved a few pieces around and got the same functionality I had before with little change to the ORM