It's an eye opener for me to read that developers would just as soon
implement blank trimming in a JavaScript client as opposed to implementing
it in the database "layer", so to speak. To me, this is the kind of
functionality that belongs "in the database" as opposed to "in the
application". So that no matter which client (browser, Node.js, PHP, Ruby,
Java, Python, .Net, whatever), they all are provided the same functionality.
In the database layer, people could create an SQL view that automatically
trimmed trailing blanks. Or IBM could provide a connection option as
suggested by Niels. But I'm ambivalent to those ideas because I have never
been in favor of providing generic SQL and program call interfaces to
clients, primary due to security concerns.
I favor providing granular web service APIs to clients.
The majority of security services offered by vendors in the IBM i space are
designed to address concerns that are derived from shops that are providing
open pathways to IBM i data and programs. In contrast, my company doesn't
run any host servers on IBM i in our production environment. We don't open
any ports on our firewall for those types of interfaces. That may seem
pedantic to some people. But it gives me some peace of mind just knowing
that those interfaces are simply not provided.
On Mon, Mar 26, 2018 at 9:05 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:
+1
midrange.com
