I'm doing exactly what you are describing, using Serge's great stuff, and it works perfectly. I'm not sure what your problem is... I just put it in with the "prepare..." function, and when I get the thing back from MySQL, pump it into an NSImage, and voila, it works fine. If it's stored in a blob, MySQL is going to give you back byte data, not hex.
> From: Ben Einstein <[EMAIL PROTECTED]> > Date: Thu, 8 May 2008 12:11:46 -0400 > To: Serge Cohen <[EMAIL PROTECTED]> > Cc: cocoa dev <cocoa-dev@lists.apple.com> > Subject: Re: BLOBs, MySQL, hex. Oh my > > Hi Serge, > > It's really quite strange. MySQL does return an NSData object, but > there's a byte level problem. Again, I really don't know much about > this stuff but NSImage instances fail to be unarchived and zip files > can't be unpacked. From what I understand, MySQL is giving us back > hex. So I used your prepareBinaryData: method, but any time I got a > query back with that data, it was no good unless I ran Hayden's hex > conversion loop. My columns I'm writing to are of type LONGBLOB. > > In regards to the Shark testing: I knew what loop was getting caught > up, I never, ever knew that Shark could get so specific as I've now > discovered. I shouldn't have dismissed that suggestion so soon. Most > of my experience with optimization is with Instuments (and their pre- > leopard counterparts), which can't get that specific (again, as far as > I know). > > Ben > > On May 8, 2008, at 9:01 AM, Serge Cohen wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello; >> >> One thing I don't understand, is that in MCPKit, you're supposed to >> "prepare" (that is hexcode) the BLOB when you perform the INSERT, >> but when using a query and fetch a row, the column containing a BLOB >> should already be returned as NSData... This NSData should represent >> the exact binary replicate of the INSERTED NSData (before it was hex- >> coded) ... >> >> In other words, to my knowledge one would need to use the - >> [MCPConnection prepareBinaryData:] method at the time of the insert, >> but there should be NO need to any back conversion when getting the >> result of a QUERY. >> >> Is there something I'm missing here ? (unless you are indeed storing >> your BLOB as a TEXT, in which case MySQL would store the hex-coded >> text rather than the binary represented by it, and in which case it >> would return the TEXT which you would have to UN-hexcode >> yourself ... if this is the case, then the problem lies in the table >> definition, you "just" have to make sure to declare the column as >> BLOB rather than TEXT, right ?) >> >> Serge. >> >> >> Le 8 mai 08 à 02:16, Ben Einstein a écrit : >> >>> Hi All, >>> >>> I have an enterprise DB application that once used DO to move some >>> files around (images and zip files, mostly). After some serious >>> testing and lots of reading, I decided to move this to a few >>> different BLOB fields in the database. Despite major warnings from >>> people, I've found that images work great (specifically, NSData/ >>> NSImage). I can notice a very minor speed drop a few milliseconds, >>> but being able to drop DO and it's woes is completely worth it. >>> >>> Unfortunately, I didn't quite test the zip files, figuring it would >>> be the same. I'm using Serge Cohen's MCPKit (aka SMySQL), which has >>> a nifty little function to convert NSData to a MySQL-legal >>> NSString. On the other end, someone on the Apple list posted a few >>> lines of code to bump returned data into it's original NSData >>> object. With the zip files (no larger then 600kb) that method takes >>> 30 - 40 seconds to run. On an image of a similar size, it takes 0.1 >>> seconds on a slow day. >>> >>> Does anyone know why this would be? Is there an easy way to get >>> around this? I suppose my understating of hex is lacking, but I >>> always thought a hex string was a hex string was a hex string; >>> length was all that mattered. >>> >>> Thanks, >>> Ben Einstein >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> >> iEYEARECAAYFAkgi+Y0ACgkQlz6UVQtc2uw04wCfR77KlokLWAk533hza8gF3WqQ >> X4EAoOMlMyytSQdFArPkOZ+uITE9OtI5 >> =aw++ >> -----END PGP SIGNATURE----- > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/chris%40clwill.com > > This email sent to [EMAIL PROTECTED] _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
