[Resolved] setGameStateValue stores integers only?

[BrianLovesMarvel]

I was trying to reduce the database footprint by using global variables. My dbmodel.sql file seems to be getting a little big. However, I don't seem to be able to get anything but integers stored with setGameStateValue(). I suppose it would be obvious from the global table definition but it is not really mentioned in the doc or comments. I was assuming I could use these variables for strings too.

In setupNewGame:

Code: Select all

	self::initGameStateLabels( array( 
			"testing_var" => 19
		) );	

	// Only accepts integer values. Strings become "0" and decimals are rounded to the nearest integer.
	self::setGameStateInitialValue( 'testing_var', "test" ); 

In stEndRound:

Code: Select all

	$testing_var = $this->getGameStateValue("testing_var");
	$descr .= " testing_var=$testing_var";

And by sending descr in a notification, I'm able to see that testing_var=0. I don't seem to be able to store a string or a decimal number.

Are the global GameStateValues always integers?

Thanks, Brian

[Tisaac]

Yes, only integers.
I usually have a Log module which basically works as some variable storage with json_encoding the variable so that I can use any type I want.

By the way, your way to build the $desc won't work with translation system.

[BrianLovesMarvel]

Thanks for confirming that. Much appreciated.

Your method sounds cool. I just made more tables and shoved the necessary things in them, but I may give your JSON encoding idea a try.

Thanks for the heads up on translations. I'm just getting started and the $descr was just a debug statement. I still have to look into the translations yet.

Brian

[JumpMaybe]

Edited: never mind

[BrianLovesMarvel]

Thanks, good to know! I may try that.

[Victoria_La]

Why would you hack it like this? Just create you own table with varchar and write db method to get and set.

[Een]

Why would you hack it like this? Just create you own table with varchar and write db method to get and set.

Yes, absolutely. A well created database structure is clear and easier to maintain that a hack of the framework or a generic table with json (and it doesn't take more space, if you have to store the data, it will take the space needed to store it in any case). If you have a limited number of strings you might also use an integer in a global and a translation array to match the strings in your material.inc.php: that's also clear and readable (and in this way it does take less database space ; but it's not an objective per se except in very specific cases, the database for a game being transient).

Please think of the admins or other devs that may want to read your code at some point to fix or improve something

[RicardoRix]

And the opposite viewpoint is why doesn't the framework already have something like this?
and instead asks every developer to reinvent the wheel.

The fact that these functions are actively prompted (in the default project and the wiki) leads the developer to believe that this method would be the best one to use for reliability and readability.

[JumpMaybe]

I asked the same question here in 2019 and no comment then:
https://boardgamearena.com/forum/viewto ... 12&t=13821

But I see this comment on this page now:
"You 'must not modify' the schemas of the global, stats or gamelog tables (and you must not access them directly with SQL queries in your PHP code)."
http://en.doc.boardgamearena.com/Game_d ... bmodel.sql

[Een]

And the opposite viewpoint is why doesn't the framework already have something like this?

Well, we can't have everything. Everything is a lot of things
We try for a good and sufficient subset of things. And we don't pretend it's perfect.

and instead asks every developer to reinvent the wheel.

Well, I don't think we do ask that. But developers do like to anyway, everyone has an idea about how round the wheel should be
That's one reason why we kept the studio very open for developers to do things their way, up to a point it's fine.

The fact that these functions are actively prompted (in the default project and the wiki) leads the developer to believe that this method would be the best one to use for reliability and readability.

Well, there is also a dbmodel.sql there. Not sure what you mean by actively prompted, but I don't think that a technique is explicitly favored above another. Using globals is perfectly fine. Using the dbmodel too.

The OP question was about the database footprint. I'm answering this: it's not a concern in general, and should not be a reason to overusing globals instead of creating a clear database structure for storing the game data. I think that for readability and maintainability, a clear database structure is better, but it depends on the specifics (I don't know the specific usecase, maybe a global is perfectly fine there).