List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:October 14 2008 11:11pm
Subject:Re: Using MySQL++ with lots and lots of data
View as plain text  
On Oct 14, 2008, at 3:20 PM, Rick Gutleber wrote:

> Do you envision the policy as an actual object (i.e., class)?

Yes.

The only other alternative that comes to mind is an enum and a switch  
statement inside insert(con, policy), but I think you will actually  
end up with multiple versions of insert(con, policy), if only due to  
the differences between sequence and associative containers.  So,  
you'd end up duplicating code if you don't factor it out somehow.

Also, people may want to create their own policy classes.  I don't  
propose to solve everyone's problem with this, just most people's. :)

> would you want a whole hierarchy or just some separate classes?

Well, since it's going to be a template method, you can do duck typing  
here: if the passed policy thingy looks like a policy object, it is a  
policy object.  No actual need for an abstract base class just to  
satisfy C++'s static type system.

> I would naturally think of a class hierarchy where everything is  
> derived from a vanilla Policy class, but honestly I don't see what  
> purpose that would serve.

Ditto.

> I would give the InsertPolicy two members, an enum to represent the  
> policy type (one of the 4 types you suggested), and an integer size  
> value.  Is the right track?

No.  This is OO without the OO.  It's the kind of ugliness you see in  
code that has to mash two different type systems together.  MySQL++  
does it internally because it has to map the SQL type system onto C++,  
though you're not supposed to see this.  (Pay no attention to the man  
behind the curtain.)  I saw this pattern again just the other day in  
an XML-RPC library, for the same sort of reason.  It's popular in a  
lot of C libraries that have to interface with OO systems.

Type-as-enum has no place in a system written entirely in a single OO  
language.  If you want a new type in an OO language, define a class.

As for the question of abstracting the size value, I guess you *could*  
put it in an abstract base class, but I think you need a better reason  
to create a class hierarchy than sharing an integer.  Especially so  
since each subclass will interpret the integer differently, and the  
base class will have no use for it at all.

> The code seems to be organized with a single class in each file,  
> which is the way I work, too.

Mostly, but not always.  Exceptions and Options all get defined in a  
single file each, because they're small and closely related.  I think  
this is another case where you want them together.  We're probably  
talking about ~100 SLOC.

> Would you want Policy class(es) to go in its (their) own file(s)?

Yes, but I would #include the header within the public section of the  
Query declaration, so they get put into its interface.  There's no  
good reason to use these classes with any other class.  The .cpp file  
then defines the methods as Query::FooPolicy::method()...

> Or maybe the policy should be a private struct....

End-user code can't create policy objects if the declaration is private.

> Or, would you prefer me to use my own judgement and show you when I  
> have something?  ;-)

That, too, but be prepared for requests to go back and rewrite it.  :)

You have read HACKERS.txt, I hope?
Thread
Using MySQL++ with lots and lots of dataRick Gutleber13 Oct
  • Re: Using MySQL++ with lots and lots of dataAndrew Sayers14 Oct
  • Re: Using MySQL++ with lots and lots of dataWarren Young14 Oct
    • Re: Using MySQL++ with lots and lots of dataRick Gutleber14 Oct
      • Re: Using MySQL++ with lots and lots of dataWarren Young15 Oct
        • Re: Using MySQL++ with lots and lots of dataRick Gutleber15 Oct
          • Re: Using MySQL++ with lots and lots of dataWarren Young15 Oct
            • Re: Using MySQL++ with lots and lots of dataRick Gutleber15 Oct
              • Re: Using MySQL++ with lots and lots of dataWarren Young15 Oct