On 9/26/11, Uwe Schroeder <uwe(at)oss4u(dot)com> wrote:
> In my experience "data formatting" goes both ways, in and out. Out is
> obviously not a major issue because errors don't cause data corruption. In,
> however, is a different issue. Errors in "inwards" conversion will cause
> data
> corruption. So unless you have an application that does very little "in" and
> a
> lot of "out", you still have to code a lot of data conversion which
> otherwise
> someone else (the postgresql developers) have already done for you.
~
Well, yes Uwe, but any code in the DBMS would slow a bit its main job
which (to me) is store data and keeping its consistency as soon as
possible
~
>> > Take dates for example: you'd have to code very carefully to catch all
>> > the different ways dates are represented on this planet.
>>
>> ~
>> Yeah! And java does an exceptionally good job at that (including
>> internationalization)
>
> Maybe it does. I never coded Java because I don't like to use technology
> where
> Oracle can come sue me :-)
~
Yeah! I felt like sh!t when I heard that Oracle had bought Sun, a
-slightly- more open company, at least they like to keep that
perception of themselves ...
~
>> http://download.oracle.com/javase/7/docs/api/java/ {util/Date.html,
>> text/DateFormat.html}
>> ~
>> So, you would ultimately just have to store a long value into the DBMS
>
> Yes, a long value - which can represent pretty much any valid and invalid
> date
> ever devised, so again you don't really know what's in the database when you
> leave the validation to the application.
~
Not if you get that long value through java ;-)
~
>> This is something I would do with wrapping code using input and
>> output bound command objects which are indexed after the same column
>> index the DBMS uses
>
> Which still depends on your use case. Your assumption is that every piece of
> code is coded in Java - which is fine if that's what your application calls
> for. It's going to be a major hassle when you ever have to re-code in a
> different language though.
~
Well, yes you are right
~
>> > To me, that's moving data integrity into the application.
>>
>> ~
>> Not exactly! Integrity is still a matter of the DBMS which can now
>> handle it in an easier way in someone write a date in bangla and
>> somebody else in Ukranian this is still the same date/time value
>> ultimately determined by the rotation of our planet around the sun ...
>> and all we need for that is a long value. Now, aren't we easying
>> things for the DBMS?
>
> I agree to disagree on this one. The date value the database stores in this
> case is a long. Any "long" can be converted into a valid date - but is it
> really the date that was entered in the first place?
~
Again, not if you get that long value through java. It takes care of
doing those checks for you. You could for example not enter 02/30/2011
as a date object in java and try to get a long out of it
~
> If I give a date
> representation, i.e. 12/31/2010 to the database, I personally don't really
> care how the database stores the date underneath. All that interests me is
> that the next time I ask for that field I get 12/31/2010 back.
~
But "12/31/2010" is ultimately a representation of that long you
would have inserted that was and can be represented in many different
ways, depending on user preferences
~
> There is no
> error that can be made other than user error if you ask the database to
> store
> a specific date representation. There are errors you can make in your own
> conversion code which can lead to a different "long" stored than intended.
~
conversion code will not be mine and it is part of java and I would
guess here python or any decent programming language
~
>> ~
>> Well, the code you will have to write either way, regardless of where
>> you keep it and in order to not even have to restart the application
>> server cold I would code command objects (like function pointers in C)
>> to handle those cases. It is ultimately a strings of characters you
>> are dealing with
>
> With the right design, you will have to rewrite the visual layer, not the
> application logic. Errors in the visual layer are of little consequence
> (except disgruntled users). So yes, if you use some kind of middleware that
> does all the converting and validating for you, the difference is
> negligible.
> But then, why write your own when the database already provides that
> functionality?
~
Because DBMS are I/O beasts and are way more likely to enter into
delayed states and concurrency conflicts, so to me, the less you
hassle them the better, for example I never handle http sessions with
a DBMS because they are very volatile, temporary and user specific. An
also, the hardware DBMSs sit on mechanically and magnetically wears
off with usage
~
On 9/26/11, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> its the old hammer and nail thing [1]. a pure Java programmer wants to
> see everything in Java as its the tool he knows.
~
Well, not exactly. I am not religious about code. The most
sophisticated code I have written in my life was in FORTRAN, but the
most amount of code I have written has been ANSI C and C++ and later
java, which I like because its hot spot technology enables it do run
time optimizations (something you can't do with statically compiled
code) which makes it faster than C on web servers
~
question: which kinds of code analysis tools do you use guys?
~
lbrtchx