Richard:
I'm not arguing with you, I just want to understand the problem and solution.
I said:
> For storing an image into MySQL I simply used:
> $image_large = mysql_real_escape_string($buffer);
Then for displaying the image, I use:
if (get_magic_quotes_gpc())
{
$fileContent = stripslashes($fileContent);
}
You said:
This is bass-ackwards...
What you've done is store the data with "double" addslashes() when
MagicQuotes are on, and then you "undo" one of them.
So your data actually in the database has an extra set of slashes on it.
That's not good clean data.
If I perform stripslashes first, then the process doesn't work.
Furthermore, according to:
http://us3.php.net/mysql_real_escape_string
This function must always (with few exceptions) be used to make data
safe before sending a query to MySQL.
As such, I used escape_string before the query. Is mine one of those
exceptions?
----
You said:
Stop confusing the hell out of yourself, and use .htaccess to turn
magic_quotes OFF and magic_quotes_runtime OFF!!!
Great idea -- I will do -- I just wanted to understand the problem.
----
You also said:
Another thought he'll have to face eventually, on this insane path of
JPEG in database storage:
What size buffer does PHP <-> MySQL have?
If your JPEG is too big, ka-boom.
Actually, it's more like "silently discard the tail end of my larger
JPEGs, and some images are broken, but it works for small images, what
did I do wrong?"
I've had that happen (half image thing). The solution is to load the
image into tmp directory, which is done anyway, and then reduce the
image to the size(s) you want before storing it into MySQL.
-----
You also said:
You really should consider using a highly-optimized large-sized-data
custom piece of wonderful software that's really MUCH better for
storing, managing, and retrieving JPEGs than MySQL...
It's called: "the file system"
You're almost for sure NOT using any real MySQL features on your JPEG
data. It's not indexed for speed of retrieval based on raw bytes.
It's not something you're going to search through the raw bytes for
eye color. MySQL will RARELY (and only for tiny files) be any faster
than the file system for retrieval. So you're just clogging up your
database with this massive chunk of data for no real reason.
I'm aware of the file system, I've used it a couple of times in my life.
Storing things in MySQL should not be based upon "If you're going to
search the field or not". MySQL storage is simply a way to store
stuff. It's not that much different than storing things on the "file
system" because all you're storing is 1's and 0's anyway, right? It
should not make any difference if file's 1's and 0's are stored on a
file system's hard drive or the files 1's and 0's are stored in a
MySQL dB, which is also stored on a hard drive, right?
Remember, the only difference here is the overhead architecture of
how to access the data -- there are no differences between 1's and
0's depending on where they are stored on a hard drive.
Now, one can argue that the time it takes to pull an image from MySQL
is different than from the file system, I've experienced that, and
it's important to me, and I will be changing my method to the file
system.
However, using MySQL for storing things does present some advantages
-- like associating related but different data types together data in
one record (it's hard to do that using a file system); moving data
from one server to another (again, it's hard to do that with a file
system); easier record keeping and editing; and if my memory serves
me right (which may be in error), there is a limit to the number of
records you can have in a directory whereas that isn't so in MySQL
(memory permitting of course).
-----
You also said:
You'll then need to start messing with BLOB data fields and
special-handling.
If what you mean in "special-handling" is what I've experienced here,
then I have to agree with you. However, all data types require some
form of "special-handling" it's just that BLOB's are not as well
understood IMO. My post to this list and the assorted answers I
received is an example of this.
For example, if I had posted "How do you store strings in MySQL?"
then I would guess that all the answers would have been the same. But
when I ask about BLOB's, I received an assortment of answers -- so
apparently, there is confusion on this list as well.
----
You also said:
Again I say, just put the damn files in the file system where they
belong.
An opinion (see below).
----
You also said:
We've been through this whole scenario on this list SOOOO many times
it's frightening! :-)
It's like watching the same episode of Twilight Zone over and over and
over. And not a good episode, either. :-)
Interesting you should say that -- Dennis Weaver appeared in a
Twilight Zone episode where he was a prisoner who was executed over
and over. Each time during the courtroom trial he tried to get
someone to believe him and delay the execution -- but unfortunately,
the Governor would always call too late with a stay of execution.
Because this scenario has been raised sooooo many times, there might
be something more to it (see blow). <Awaiting a call from the
Governor>.
----
You also said:
For that matter, stop trying to cram your JPEGs into your database in
the first place, and you'll also be a lot less frustrated.
"Frustrated" is a byproduct of my profession and is usually inversely
proportional to talent. But, In my case, lacking talent and
compensating with hard work, is the way I learn.
Thus far, as I said before, the only difference *I* have experienced
in storing images in a dB rather than in a file system is the time it
takes to retrieve and display an image in a web page. Unfortunately,
pulling an image from a dB does take longer and I'm now forced to
switch from using BLOB's to url's.
However, all the other concerns I've heard against using BLOB's thus
far have not been accurate IMO. There are a lot of misconceptions,
even published in respectable books, as to why one should not use
BLOB's. But, I personally think that it's problems like what I've
experienced here, which has nothing to do with BLOB's, that lead to
apprehension about their use.
No offense to anyone, but I claim that if you don't really know what
the actual limitations and advantages of something are, then you are
the one who is limited and at a disadvantage.
tedd
As my grandson once said "There are 10 types of people in the world
-- those who understand binary and those who do not."
--
--------------------------------------------------------------------------------
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
