List:MySQL++« Previous MessageNext Message »
From:Jim Langston Date:September 26 2006 5:14pm
Subject:Can/should this be added to MySQL++?
View as plain text  
MySQL++ didn't do some of the things I wanted it to do, so I wound up
writing my own wrapper for MySQL.  But I think it would be good if these
could be added to MySQL++, but I'm not sure if they would conflict.

The main thing my class does is it allows a user class/structure to be
mapped like this:


void CCharFieldMap::SetMap( CCharacter* Base )
{
    SetBase( Base );
    SetOffset( "Version", Base->Version );
    SetOffset( "Name", Base->Name );
    SetOffset( "Password", Base->Password );
    SetOffset( "Avatar", Base->Avatar );
    SetOffset( "Race", *reinterpret_cast<unsigned int*>( &Base->Race ) );
    SetOffset( "Sex", *reinterpret_cast<unsigned int*>( &Base->Sex ) );
    SetOffset( "GM", Base->GM );
    SetOffset( "GMLevel", Base->GMLevel );
    // Health
    SetOffset( "Mana", Base->Health.Mana_ );
    SetOffset( "ManaMax", Base->Health.ManaMax_ );
    SetOffset( "Overall", Base->Health.Parts[BP_None].Current_ );
    SetOffset( "OverallMax", Base->Health.Parts[BP_None].Max_ );
    SetOffset( "Head", Base->Health.Parts[BP_Head].Current_ );

   // Many of these for fields in the db

}

The reason I set this up is so I can do this:

    CCharacter Player;
    Player.FieldMap.SetMap( &Player );

    CMySQLTable PlayerTable;

    if ( ! PlayerTable.init( "192.168.1.100", "serpardum", "likeidtellyou",
"abyssal", "players", 3307 ) )
    {
        std::cerr << "Initialization failed of Player table" << std::endl;
        std::string wait;
        std::getline( std::cin, wait );

        return 1;
    }

    if ( ! PlayerTable.LoadTable( "Name", "Serpardum" ) )
        std::cout << "Serpardum not found" << std::endl;
    else
        PlayerTable.OutputMapByColumn();

    PlayerTable >> Player;

At this point the Player instance has been loaded with the fields from the
db, all handled by the CMySQLTable class.  I also allow

   PlayerTable << Player;

to set the fields in the table so I can .update() or .insert() them.

I figured it this way.  Yes, the user has to map each field, but then, if
they are loading the fields they are going to have to go through each field
one way or another anyway.  Either with << or some other method.  So I
figure do it once and get it over with, then you can load, update, insert,
etc.. without having to do it again.

Of couse one size doesnt' always fit all so I've overloaded other things
too.

    PlayerTable["Name"] = "Insert Test";

    PlayerTable.Update( "Name", PlayerTable["Name"].Value() );

This only sets the "Name" field.  The parms added to the Update are the key
name and value to find for the update used in the select (update blah blah
where Name = Value.

Of course you can also say:

std::string NameField = PlayerTable["Name"];

The main things being overriden exposed are =, >>, << and []

How hard would it be to implement this in MySQL++ if it even should?
Incidently, the .init() call builds an internal map of the fields with the
field names and types so the user doesn't have to, just map the field name
with the offset into the class.

Of course, one size doesn't fit all, especially for player classes that are
some form of linked list or something so they can also do this:

void CSkill::MySQLWrite( CMySQLTable& ms, const std::string& PlayerName,
const std::string& Prefix ) const
{
    if ( Name_.length() > 0 && ( Value_ != 0.0 || Active_ ) )
    {
        ms["PlayerName"] = PlayerName;
        ms["Name"] = Prefix + Name_;
        ms["Value"] = Value_;
        ms["Active"] = Active_;
        ms["Activated"] = Activated_;
        ms.Insert();
    }
    for ( std::map< std::string, CSkill >::const_iterator it =
Skills_.begin(); it != Skills_.end(); ++it )
    {
        (*it).second.MySQLWrite( ms, PlayerName, ( Name_.length() > 0 ?
Prefix + Name_ + "|" : "" ) );
    }
}

I guess my question is, is this something people other than me would want?
If enough people would want this and I get the okay from the MySQL++ team I
can look at implementing this into MySQL++

Thread
Can/should this be added to MySQL++?Jim Langston26 Sep
  • Re: Can/should this be added to MySQL++?Warren Young27 Sep
    • Re: Can/should this be added to MySQL++?Jim Langston27 Sep
      • Re: Can/should this be added to MySQL++?Warren Young28 Sep