[Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 2PM EST - RQLQueryLanguage

[Dave Scott]

Dave Dribin wrote:
 >Actually, that wasn't a strong motivation for RQL.  As someone said
 >earlier, if you pass RQL right to your DB, you are opening yourself
 >up to SQL injection attacks.  I think even with limited permissions,
 >you would still need to be very, very careful.  Do you want someone
 >doing a joins or subselects or some other bit of SQL that could grind
 >your database to a halt?  Maybe there's columns there they shouldn't
 >be seeing.  Maybe the RETS schema doesn't map to the actual database
 >schema, and the RETS server needs to piece things together.  I think
 >RETS2 is still meant to be a layer of abstraction in front of the
 >database.

I guess I can only repeat that (1) if you set up security on your  
view appropriately, most of this is not a worry; and (2) my basic  
point had nothing to do with eliminating all intermediate  
processing.  Rather, my point is that if you extend SQL instead of  
just subsetting it, you will lose some of the potential advantages of  
moving the RETS query language towards SQL.  This seems obvious.  I'd  
think that the best response to my message would be a response that  
shows that the benefit of using "ALL IN" outweighs the advantages of  
guaranteeing that any RQL compliant query is also a SQL compliant one.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20060314/cd211ef4/attachment-0001.html