- Dec 06, 2012
-
-
Peter Rotich authored
-
- Oct 15, 2012
-
-
Peter Rotich authored
-
- Sep 18, 2012
-
-
Jared Hancock authored
-
Jared Hancock authored
-
- Sep 14, 2012
-
-
Jared Hancock authored
This will remove the upper limit of BLOB sizes imposed by MySQL with the max_allowed_packet setting completely. This adds a new table %file_chunk which will contain the filedata in smaller chunks (256kB). It also includes a new class, AttachmentChunkedData, which will handle reading and writing the data, abstracting away the chunks. This is done by migrating data from the %file table to the %file_chunk table. One must beware that this must safely (the migration that is) plug into the both the live osTicket developers as well as the users doing a full upgrade from osTicket-1.6*. For this, the AttachmentFile::save method was patched to use the new AttachmentChunkedData class to write the attachment data to the database in chunks. That is, the migrater will use the new code on the major upgrade and bypass the filedata column of the %file table altogether. Therefore, the patch associated with this commit will not migrate any data for the major upgrade. For developers doing incremental upgrades, the patch included in this commit will transfer the data from the %file data to the new %file_chunk table by chunking it. As written, only the first 16MB of the attachment is migrated. This could easily be adjusted, but it seems like a reasonable limit for now.
-
- Sep 07, 2012
-
-
Jared Hancock authored
MySQL is kind enough to quietly truncate the filedata field when attempting to CONCAT data beyond the size of max_allowed_packet. The simplest fix is to automatically adjust the max_allowed_packet to the size of the file being uploaded plus some extra. See MySQL bugs #22853, #34782, and #63919 for more discussion on the issue. The max_allowed_packet variable default to 1M, but is expandable to 1G. Therefore, the fixed limit of attachments for osTicket will be 1G, since it would be impossible for MySQL to append data after that mark. *Sigh*
-
- Sep 05, 2012
-
-
Jared Hancock authored
MySQL has a limit on the maximum amount that can be transferred in one statement. It's the max_allowed_packet setting. The value of this setting will be the approximate upper limit of attachments that can be handled by the database given the current access model for osTicket. The issue came up for attachment uploads and was corrected, so that uploads are chunk inserted into the database. Downloads, however, were forgotten. Strangely, it took quite a bit of debugging to track down the problem. This patch corrects attachment downloads by fetching 256kB chunks of the attachment at a time and sending them directly to the client. This will also overcome PHP's memory limit which would be the second-level blocker of attachment sizes. Lastly, the AttachmentFile::getData() method is simulated using output buffering. This will provide the same access as the previous getData() method; however, it is still subject ot PHP's memory limits.
-
- Aug 13, 2012
-
-
Jared Hancock authored
-
- Jul 25, 2012
-
-
Peter Rotich authored
-
- Jun 28, 2012
-
-
Jared Hancock authored
This overcomes the eventual limit of and database to support queries of a finite length. We now split the file contents into 100k chunks and append the chunks to the database one chunk at a time.
-
- Mar 23, 2012
-
-
Peter Rotich authored
-
- Mar 21, 2012
-
-
Jared Hancock authored
Also add a cron job to perform the task on demand Change the implementation for Ticket::deleteAttachments to call this method after simply removing all entries from the %ticket_attachment table
-
- Mar 19, 2012
-
-
Jared Hancock authored
-