CodeIgniter Forums

Full Version: preg_match(): Compilation failed: regular expression is too large
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hello!

Quote:Severity: Warning --> preg_match(): Compilation failed: regular expression is too large at offset 48136 /system/database/DB_query_builder.php 2336

Lines:
PHP Code:
for ($ci 0$cc count($conditions); $ci $cc$ci++)
                {
                    if ((
$op $this->_get_operator($conditions[$ci])) === FALSE
                        
OR ! preg_match('/^(\(?)(.*)('.preg_quote($op'/').')\s*(.*(?<!\)))?(\)?)$/i'$conditions[$ci], $matches))
                    {
                        continue;
                    } 
I guess the question is what king of query are you running that's causing it to break? How big is the resultset? I've never encountered that error in CI.

You can always try and raise the pcre.backtrack_limit and pcre.recursion_limit settings in your php.ini. If you google that error you will find info "Compilation failed: regular expression is too large"
It's not an CI problem its an problem of the regx itself. it's to big and run into an recursion limit. The only way to handle this correctly is to think about an smaller solution.
Hello, I also get this error !

I didn't have it before updrading to codeigniter3.
The workaround I found (end of post) is temporary and you don't want to leave it like that, it is a security breach.

My usecase is a BIG where_in with tousands IDs. Increasing temporarly the ini value does not work.
What should I do ?

Sincerely 
Nicolas

PHP Code:
if (strlen($conditions[$ci]) > 10000) {
//                        ini_set("pcre.backtrack_limit", 100000000000);
//                        ini_set("pcre.recursion_limit", 10000000000);
                        
continue;
                    } else {
                        if (
                            ( 
$op $this->_get_operator$conditions$ci ] ) ) === false
                            
OR ! preg_match'/^(\(?)(.*)(' preg_quote$op'/' ) . ')\s*(.*(?<!\)))?(\)?)$/i'$conditions$ci ], $matches )
                        ) {
                            continue;
                        }
                    } 
The problem persists and the topic is current. It can not be somehow easier to solve?
(08-10-2015, 06:13 AM)RobotXX Wrote: [ -> ]The problem persists and the topic is current. It can not be somehow easier to solve?

Yes:

1. When you've got hundreds of lines of SQL, use a raw query() instead of shoving it into the Query Builder.
2. Abstract some of that logic into the database itself (e.g. IN(SELECT * FROM table_name) instead of IN(...thousands of items ...)).
if you can not rebuild somehow to bypass the bigger question? Without using the object: query() ?
has anyone created a helper method to update 5 columns in a table with a very large where_in array? I am going to write a method for this; but if someone already has a similar method I would love to use that.
I was able to write my own method and use simple_query...Is this the right method to use for RAW queries without regex issue?

(09-23-2015, 06:57 PM)blasto333 Wrote: [ -> ]has anyone created a helper method to update 5 columns in a table with a very large where_in array? I am going to write a method for this; but if someone already has a similar method I would love to use that.
(09-24-2015, 07:29 AM)blasto333 Wrote: [ -> ]I was able to write my own method and use simple_query...Is this the right method to use for RAW queries without regex issue?


(09-23-2015, 06:57 PM)blasto333 Wrote: [ -> ]has anyone created a helper method to update 5 columns in a table with a very large where_in array? I am going to write a method for this; but if someone already has a similar method I would love to use that.

It's not a wrong one, but unless this "large where_in array" is user input (and that just sounds unlikely), I'd still question why do you have to pass it from PHP to the database. Because, if my assumption is correct, the values in that array are actally fetched from that same database, which means you could do UPDATE x = y WHERE z IN(subquery).
Pages: 1 2