Sure, we're using GreenSQL. I don't know much about it, but I do know that our admin had to create a specific policy to allow all queries so that the commit would succeed. -Ben
On Jul 26, 2012, at 1:50 PM, Jarek Jarcec Cecho wrote: > Hi Ben, > could you talk more about the DB firewall you're using? I've tested scenario > when user had only "select" MySQL permission on table and commit was > successful without any issues (nor error nor warning). > > Jarcec > > On Jul 26, 2012, at 10:37 PM, Ben Flint wrote: > >> Thanks, Jarcec. I agree that there's no harm, but it's probably not a best >> practice. In my case, the problem is that our security guy only wants to >> grant read privileges on this particular db. If he insists on enforcing >> that, then I'm out of luck with the import. >> >> -Ben >> >> >> On Jul 26, 2012, at 1:06 PM, Jarek Jarcec Cecho wrote: >> >>> I believe I saw the commit command in the code, so I do agree that sqoop is >>> really doing that. >>> >>> But I do have more general question - what is wrong on doing commit on >>> transaction that did not alter any data? I believe that it's fully valid >>> operation and I do not quite see why your security guys are freaking out. >>> >>> Anyway, if you feel that sqoop shouldn't be doing that, please file a JIRA >>> on https://issues.apache.org/jira/browse/SQOOP. >>> >>> Jarcec >>> >>> On Jul 26, 2012, at 9:56 PM, Ben Flint wrote: >>> >>>> All, >>>> I am trying to do a sqoop import from a mysql server that is protected by >>>> a DB firewall. After some back and forth with my infosec guy, we >>>> determined that my import was failing because it was trying to do a commit >>>> (to the information_schema db, I believe). Can someone please tell me why >>>> the import issues a commit command? Also, is there any way to get around >>>> this so my security guy doesn't freak out? >>>> >>>> Thanks, >>>> Ben >>> >> >
