in reply to Re: Another Opinion Request...(config file)
in thread Another Opinion Request...(config file)

draconis, I don't really know what you mean, can you explain a little more?
I'm sorry, but you lost me ;(

Thank you very much!
Richard
  • Comment on Re: Re: Another Opinion Request...(config file)

Replies are listed 'Best First'.
Re: Re: Re: Another Opinion Request...(config file)
by draconis (Scribe) on May 12, 2003 at 21:54 UTC
    Let me see if I can make this a bit more clear. After your comments I can see how you might have been confused. Now, after 5 hours of meetings, this might get more confusing but lets hope not.

    By adding a field to the table that you want to store your generic "name" and "value" fields into - you increase it's ability to accept values for different reasons exponentially (or is it geometrically?). My suggestion is to add another field - call it "type". This new field would contain a value that you could use to group all your variables together with. Kinda like tieing a bunch of sticks together so that when you grab the bunch your get them all - same idea with the data fetching routine - grab them by "type" not by variable name. If you do this you limit the Disk I/O and optimize the use of buffering available for which ever data base engine you are using.

    This new field now groups all your variables - you fetch them (using your WHERE clause by including the new "type" field). Once you have all your vairables - you can allow the user to alter them in any fashion you wish. Or for that matter, the program can alter them in any fashion it wishes.

    Ok - with that understanding - now you can extend any database table without having to specifically add new fields to existing tables - you simply add data to an already existing table - this new data allows you to group, identify and quantify the new field data. So - for instance - there is an already existing table named MonthlyStats - you need a field for MeanSales - you simple add a record in the the "other" table (the one you added "type" to) type = MonthlyStats, name - MeanSales, value=1,200,000.00.

    If you add some "smart comments" into your code where you place these "hooks" - you can then later search and replace this code with code that looks at the parent table (the one you extended) - this of course assumes that the "quick fix" you did to avoid having to bring the database server down for maintenance to add a field earlier has at some point been done. Oh yeah - you would have to create a data migration utility to take the data from one table to the parent.

    If this is still confusing (as I'm sure it is) - just drop me a note and I will forward you my phone number. Maybe I can explain this better in that context.

      Ok, I think I understand now... Let me see if I can make it clear, and please tell me if I am way off base or not... :o)

      Ok, I have these fields currently in my DB:
      name content
      I should add one called "type".

      Then when I call the variables I should do it in one big swipe:
      get_page_content("some_type");
      Something like that, and it would then go load each value for that type?
      Here is how I currently do it:
      $default_font_family = get_page_content("default_font_family");
      Each variables '$default_font_family' is the same name in the db: 'default_font_family'.
      So how could I do that, where it will take the "name" and make it a variable, without telling it like I do: 'name = sub('name');'
      Could I do something like this in the subroutine:
      my $type = shift; my $dbh = DB_File::connect(); $sth = $dbh->prepare (qq{ SELECT name,content FROM page_vars WHERE + type = ? }); $sth->execute($type); while ( my ($db_name,$db_content) = $sth->fetchrow_hashref() ) { ${$db_name} = $db_content; } $sth->finish(); return 1;
      Would that work? I don't think it would, but I have not tried it. Do you know off hand if it would work?

      If not I suppose I could put them in a hash or array:
      my $type = shift; my $dbh = DB_File::connect(); $sth = $dbh->prepare (qq{ SELECT name,content FROM page_vars WHERE + type = ? }); $sth->execute($type); my %vars; while (my ($db_name,$db_content) = $sth->fetchrow_hashref()) { $vars{$db_name} = $db_content; } $sth->finish(); return(%vars);
      Then I could just have each variable instead of being called by the name be called by a hash:
      instead of doing: $default_font_family = ... do this: %vars = get_page_content("some_type");
      Then %vars would contain all the variables so I could print them by doing:
      $vars{default_font_family}
      The only bad thing about using the hash, is that I have already done a lot of work, where I don't do that, so I'd have to put a whole lot of time into search and replace :o)

      Anyways, did I understand it the way you meant it?

      Thank you much, as usual!
      Richard
        Looks to me like you got it !

        I would take the approach of using the hash to store the key/value pairs which end up being your variables with their respective values.

        Please let me know how you make out with this.

      One quick question...

      What did you mean by this:
      >you simple add a record in the the "other" table
      >(the one you added "type" to)

      What is "other"? Is that a "type"?

      thx,
      Richard
        Sorry - you are right - that wasn't too clear - kinda like muddy water. At any rate, the "other" table is the table that you store your name and value fields - where you are storing the variables.