| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
of them.
|
|
|
|
|
|
|
|
| |
safe. From now on, always use [self lockConnection] rather than [queryLock lock], independent of what thread you are running on
- A warning is written to the console when the connection is unlocked multiple times (to identify potential race conditions)
- modified MCPStreamingResult to ensure it only closes the connection once
- added a check to prevent arrow key navigation past the last row
|
|
|
|
| |
during static analysis.
|
|
|
|
| |
rather than the data processing thread. This ensures the connection unlock is walys called - even when no data is present - thus addressing Issue #594. (Prior to r1931 manual memory management caught this case anyway)
|
|
|
|
|
|
|
|
|
| |
crashes: prevent multiple disconnects, add more checks, cancel current queries, and add a tiny delay to allow mysql cleanup.
- Alter MCPStreamingResult to no longer return a retained instance, setting up correct result disposal on autorelease but changing callers to retain as soon as they receive.
- Review and change a number of local variables shadowing/shielding other local or global variables.
|
|
|
|
| |
variables, a few leaks, and additional nil setting/checking to prevent overreleases or releases of random areas of memory.
|
|
|
|
|
|
|
| |
to avoid binary-mode result issues with certain versions of MySQL (including 4.1.14). This should address Issue #509.
- TableDocument now requests the server version string from MCPConnection, aiding caching
|
|
|
|
| |
MCPStreamingConnection for a ~10-15% speedup in CPU-bound loops (eg data sets with lots of rows but little data) by reducing lock contention. (To be tested against #463)
|
|
|
|
|
|
|
| |
an occasional crasher when getting table cells by adding a retain
- Alter MCPStreamingResult to use pthread mutexes in a further attempt to address Issue #463
|
|
|
|
|
|
|
|
| |
at the bottom. This addresses the last of Issue #49 and implements Issue #133; jump-to and two prefs affecting loading are available in a popup when clicking the pagination interface.
- Format row counts at the bottom of the content pane
- Increase the MCPStreamingResult buffer for a stronger workaround for #463
|
|
|
|
| |
processing rows - eg don't process the newly downloaded rows at once - as a workaround for Issue #463
|
|
|
|
| |
results. This improves partial content displays (using the new code as of r1530) and also improves custom query error reporting.
|
| |
|
|
|
|
|
|
|
| |
structure view. Fixes issue #223.
- Fix for correctly displaying data within fields of type BINARY/VARBINARY. Fixes issue #348.
|
|
|
|
| |
data types.
|
|
|
|
|
|
|
| |
- Significantly improve memory usage
- Minor speedup (1.1x faster?) to overall query/display times
- Improvements to MCPStreamingResult and MCPConnection to accurately report affected row count
|
|
|
|
|
|
|
| |
- Speed up table content processing a bit
- Make the table content download/processing determinate where an approximate row count is available
- Clean up table content source, assuming MCPStreamingResult will remain in use
|
|
|
|
|
| |
- do not check "if (rowDataLength)" due to the fact that a row could have the length 0 ( if all columns are set to NULL ), otherwise the entire row will be set to NULL and this causes a mismatch in the number of columns for that row later on
• minor code cleaning (indentions)
|
|
|
|
|
|
|
| |
download all results as fast as possible from the server, to avoid blocking, but do so in a background thread to allow results processing to start as soon as data is available. Many thanks to Hans-Jörg Bibiko for assistance with this.
- Add an option to the SQL export dialog to allow selection of the full-streaming method, with a warning that it may block table UPDATES/INSERTS.
|
| |
|
|
- Added an MCPStreamingResult class to MCPKit, to allow streaming results from the server including fast array access of each row
- Tweak SQL export to use the streaming result class and to keep memory usage lower
End result is generally faster exports, more accurate progress bars, and much much lower (and consistent) memory usage.
|