When I build interfaces on top of a pre-established database schema, I usually can't change schema properties. That's a problem when working with a "convention over configuration" MVC Framework like cakephp.
After baking/scaffolding a CRUD interface based on a "join table" (HABTM) class, that issue came into focus, once again. I have had run into some fairly easily resolvable issues involving some non conventional naming in the schema, such as primary key names. I had primary key names from different tables that included the table prefix as well as irregular pluralization in the names. Initially I wasn't able to get my dropdowns to populate from related tables, as described in the previous post. Then I ran into an even stickier problem: the save method would fail on validation in the add method of the join table controller.
As it turned out, the form helper input method, though it would accept various names (probably cake-conventional) to refer to itself and to the primary key field, would not accept the ACTUAL name of the primary key field (which, while cake-unconventional, was actually set in both its own class model using $primaryKey and the join model using $foreignKey -- BTW, the same name was in use in the join table database, so this was really convention over configuration coming back to bite me).
To fix this I added the following to the controller to remap the cake-conventional failing field names to the actual (working!) field names:
I discovered, subsequently, that defining foreignKey (of parent) in child class models fixes some issues ... may even fix issue that I describe above.
Relates to: Cakephp SQL Error 1054 Unknown Column In The Field List (id column)
To my knowledge, there's no way to "autopopulate" a form created through cakephp's bake/scaffold utility. Populating of the forms are also not well documented. Here's how you do it, with a related table via foreign key in the database.
For various reasons, I had found I needed to be root to install ArcGIS Server on Centos.
I ran into my first problem with that configuration on patching, when the script halts with the following message "You must install this [patch] as ArcGIS Server Owner, do not install it as ROOT user." I was able to successfully bypass this by commenting out this if block from the patch script (applypatch).
When our cluster was upgraded, I somehow lost the ability to run ArcGIS Server. No problem, I said, I'll just rebuild the machine. This is where I was again reminded that ArcGIS Server installation is very different from other Linux software.
The biggest issue is that ArcGIS installers will only run when logged in root. Yeah, not running a bash as root, or sudo'ing as root, or su'ing to root ... you actually have to log in as root.
Herein lies the difficulty: the rest of the installer assumes a GUI (e.g., gnome or kde). You can't login to gnome or kde as root.
If you're doing best practice X tunneling with SSH, then you're using private/public keys. So make sure that you create a .ssh profile with keys and copy over the authorized_keys directory from your normal user. I think this is where my immediate stumbling block was: when I first did this I wasn't thinking as much about security, just seeing if it would work. I didn't use keys. When I rebuilt the system, I did ... and of course I disabled plaintext passwords. I didn't even consider that I'd want to login as root through X/SSH, but I'd guarantee that's how I did it the first time. This was also an issue with X, specifically, because X settings (e.g., $DISPLAY) would only be set for the logged in connection (my normal login) and not root, if not connected directly with root.
[root@host]# cd .ssh/authorized_keys .
Finally, of course, everything ArcGIS runs through Wine on Linux (the Windows compatibility layer). It turned out there was a profile directory that was owned by another use
C:\OSGeo4W64>gdal_translate -of KMLSUPEROVERLAY FORMAT=JPEG with an example path, this looks like: C:\OSGeo4W64>gdal_translate -of KMLSUPEROVERLAY D:\downloads\tile177_12orthos\177.tif D:\downloads\tile177_12orthos\177.kml -co FORMAT=JPEG This will output a tiled images with a KML to tie them all together.
On running sqlite CREATE and INSERT queries, I was getting some mysterious errors, like "Error: disk I/O error", despite having the proper permissions on the .sqlite file and adequate space in the directory. I then broke down the compound query to a simple query and was getting "GEOS error: IllegalArgumentException: Points of LinearRing do not form a closed linestring", though I found that doing Hex(PolygonFromText(...)) did return a hex string. My WKT was, however, poorly formed. WKT requires that the final coordinate pair and the beginning coordinate pair are the same, as in PolyFromText('POLYGON((-75.8 38.4, -75.0 38.4, -75.0 39.85, -75.8 39.85))',4236). After I fixed that, my more complex queries were able to run successfully.