db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: Binary data using Torque
Date Mon, 07 Nov 2005 23:32:07 GMT


> -----Original Message-----
> From: Thomas Fischer
> 
> "Greg Monroe" <Greg.Monroe@DukeCE.com> schrieb am 01.11.2005 16:12:40:
> 
> > Just curious... wouldn't you want to use a BLOB type for stuff like 
> > this? Since it's variable and BINARY is fixed?  Either way, both 
> > should work.
> 
> What do you mean with "Binary is fixed ?" I am no postgresql 
> expert, but as far as I know, bytea can store variable length 
> data. And _IF_ blob is mapped at all for postgresql, I would 
> bet my head it is mapped to bytea as well. Maybe there are 
> other databases where the Torque Type "BINARY" is mapped to a 
> data type which requires size specification, but Postgresql 
> is not one of them.

Sorry, mentally keyed on BINARY which is fixed and didn't 
remember VARBINARY.  But FWIW, with MS SQL, Torque maps an 
unsized BINARY to a MSSQL BINARY field of 7132 bytes. (MS 
SQL BINARY fields have limit of 8000 bytes as well.)  
VARBINARY maps to an MS IMAGE fields which had a more 
reasonable 2^31-1 max length.

I also checked MySQL and found that it maps to BLOB / 
MEDIUMBLOG / LONGBLOB for all BINARY types (sized or not).

Seems like there's some possible problems with DB independent 
coding using the BINARY types.

> 
> >
> > One issue with both types is that you have to read the file into 
> > memory to store it since both type are set via a Java 
> byte[] objects.  
> > It might be nice for blobs/clobs to support the java.sql.Blob/Clob 
> > interfaces in some way.  Not sure how to work this Torque's current 
> > Village underpinning though, but I haven't dug into it at all.
> 
> Not so sure about that. From the point of view of a db 
> abstraction layer, in the ideal calse, all you want to do is 
> save data into the db and read it again, you do not want to 
> use the internal logic needed to do that. So what would be 
> gained from havin the clob/blob handles available ? As I 
> understand it, the value about having handles would be to 
> decide yourself whether you read the data or not (this can 
> bring performance gains as blob/clob data is typically 
> large). But this can also be achieved in another way: Put the 
> blob/clob data in another table which has a 1:1 relation to 
> the original one, and read the extra table only if its needed.

I was thinking that by using CLOB/BLOB "handles" rather than a 
binary array, the "effeciency coding" is passed on to the JDBC 
implimentor. If you've got a good JDBC implimentation, when you
use the BLOB/CLOB *Stream methods, it will probably handle 
buffering the reads and writes to the DB for you rather than
caching it in memory.

FWIW, I get worried about caching pictures in memory since we 
do "face book" pages that have pictures and names with a lot of 
people.  Often, the pictures are user uploaded and end up being 
"photo-quality" (e.g. 500K+) in size.  But this is all just 
part of dealing with large memory hog coding, and you always
have to recognize when your dealing with this sort of situation
and try to do the right thing.

 
> >
> > FWIW, I've always found that putting pictures into a DB is 
> generally 
> > causes more performance problems than any benefits gained.  Much 
> > easier just to upload the file with a unique name to a resources 
> > directory and then store the URL/reference info in the DB. 
> But that's 
> > just a personal view.
> >
> 
> Depends on whether you run your application in a cluster or 
> not. On a single server, the file system is fine. On a 
> clustered system, syncing the file systems is problematic in 
> my experience.
 
Good point. Application context is always king in design...just
be careful not to over architect for your needs.

> > > -----Original Message-----
> > > From: Thomas Fischer [mailto:tfischer@apache.org]
> > >
> > > Yes, its possible. Postgresql has the bytea data type for storing 
> > > binary data. Use the Torque type BINARY for it.
> > >
> > >     Thomas
> > >
> > > On Wed, 26 Oct 2005, Jakub Piechnik wrote:
> > >
> > > > Hello
> > > >
> > > > I wonder if it's possible to handle binary data with Torque. I 
> > > > mean that for example there is a picture file (gif) and 
> I want to 
> > > > put it
> > > in my database
> > > > (Postgresql). Is it possible to do that using Torque and if
> > > so - how should I
> > > > try to use it
> > > >
> > > > Regards
> > > > Jakub Piechnik
> > > >
> > > >
> > > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > > For additional commands, e-mail: torque-user-help@db.apache.org
> > > >
> > > >
> > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > For additional commands, e-mail: torque-user-help@db.apache.org
> > >
> > >
> >
> > Duke CE Privacy Statement
> > Please be advised that this e-mail and any files 
> transmitted with it 
> > are confidential communication or may otherwise be privileged or 
> > confidential and are intended solely for the individual or 
> entity to 
> > whom they are addressed.  If you are not the intended recipient you 
> > may not rely on the contents of this email or any 
> attachments, and we 
> > ask that you  please not read, copy or retransmit this 
> communication, 
> > but reply to the sender and destroy the email, its 
> contents, and all 
> > copies thereof immediately.  Any unauthorized dissemination, 
> > distribution or copying of this communication is strictly 
> prohibited.
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-user-help@db.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message