On Nov 18, 2008, at 3:51 PM, Michael O wrote:
> About the rewrite. I assume you are still working on it.
No. MySQL++ policy is to not check in code unless it at least
compiles, and ideally makes for a complete feature.
> It failed when I compiled: The error was missing image.h.I decided
> to go see if I could use the same link you game me and the header
> files had nothing in it but one line and 2 empty #includes.
I think you must have guessed the wrong URL. Here's the correct one:
http://svn.gna.org/viewcvs/*checkout*/mysqlpp/trunk/examples/images.h
It looks fine to me.
> Do you recomend storing images into the database
Personally, I don't like using BLOBs much at all. I think they
violate an important precept of database theory, which is that each
column should contain just one thing. Is an image just one thing, or
is it, as the poets insist, a stand-in for a thousand words? What
about other binary formats, like ZIP or MPEG files, which naturally
represent many things assembled together?
My company's use of MySQL++ has an area where it *could* store images
in the DB, but it doesn't. We store the images for a particular table
outside the DB, with the files named after the key field of the table
they're attached to.
When there's a web server involved, it works even better to store
images outside the DB, because then you can just point the web server
at the directory where the images live, and don't need to do DB
lookups at all. It allows for better caching logic, too.
The purpose of the load_jpeg/cgi_jpeg pair isn't so much to endorse
images in BLOB columns, but just to show that it can be done, and
how. I do believe there are justifiable uses for BLOB columns, but I
find that they're often specialized uses, so they don't make good
examples.
> P.S. The files online have no formatting with them they are all just
> one line
That's probably a Windows vs. Unix sort of thing. You'll have better
luck if you check the svn version out with a proper Subversion client,
rather than go through the web interface.
