• user warning: Unknown column 'u.signature_format' in 'field list' query: SELECT c.cid as cid,, c.nid, c.subject, c.comment, c.format, c.timestamp,, c.mail, c.homepage, u.uid, AS registered_name, u.signature, u.signature_format, u.picture,, c.thread, c.status FROM comments c INNER JOIN users u ON c.uid = u.uid WHERE c.nid = 26786 AND c.status = 0 ORDER BY c.cid LIMIT 0, 50 in /var/www/ on line 991.
  • warning: file_get_contents( [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /var/www/ : eval()'d code on line 4.

CodeExport Updated

by Josh Fletcher

Today I posted an update to the CodeExport GitHub project to remove its one and only plug-in dependency (for compile-time at least). Thanks to Kirk Brooks for pointing out the problem! Read on to find out what I did.



CodeExport uses the MISC I plug-in (created by Keisuke Miyako - he's also on GitHub!) to get the OS-level process ID of the 4D application. This value is in turn used via a batch/script file to wait for 4D to quit before taking care of a component build.


The problem was the presence of the plug-in call created a compile-time dependency.  CodeExport by its very nature is an interpreted component (the Design Object Acess commands cannot be used in compiled mode) so when the component is dropped into a host database it becomes part of the compile process. Thus anyone using CodeExport had to also install the MISC I plug-in. This really bugged me, it's completely the opposite of what I was trying to achieve with CodeExport; I want CodeExport to be zero-impact on the host database (and on the developer).


Luckily the solution to this problem was an easy one. The super-cool 4D command EXECUTE METHOD was all I needed. I wrapped up the plug-in call (PROCESS Get ID) in a 4D Project Method (UTIL_Get4DProcessID) and used EXECUTE METHOD to call this method instead of calling it directly. 4D's compiler doesn't follow this call chain, so the plug-in dependency is mitigated (the plug-in is still required for a build of course).


All in all it was a fairly painless solution and a classic example of one of the pitfalls when understanding component vs. matrix database design.


Note that today's update removed the "Plugins" folder from the root of the GitHub project.  If you're looking for a copy of the MISC I plug-in there's one in the matrix database or you can download it directly.


Reminder: if you want to make sure you have the latest version of CodeExport, just look for the text file inside the component package and compare it to the one on GitHub.

RSS 0 comment(s) to this post