On Wed, 2010-12-15 at 14:07 +0100, David Sommerseth wrote:
> > The sql side is easy enough - the point you are missing is that you have
> > access to any number of jdbc connections/versions at once (say you want
> > to copy among different database types) and also to anything else
> > already available as a java jar or source. Writing the code to display
> > a graph on most platforms is the part I thought would take you a
> > substantial amount of time, where with groovy you can include swing and
> > jfreereport and hand it some values.
> I planned to stay out of this discussion. But when I see claims that
> jdbc connections and doing copy between/among different database types,
> I must raise my voice.
> Most databases to indeed follow SQL standards. But there are several
> SQL standards (SQL92, SQL98), and then you have different
> interpretations of them. So a INSERT statement which works flawlessly
> against a MySQL database might not work against PostgreSQL, SQLite or
> Oracle - due to that the MySQL syntax might not follow a defined SQL
> standard.
> Then you can have a SQL query working flawlessly against PostgreSQL, but
> it uses features only available to PostgreSQL, like SEQUENCE. So
> Oracle, SQLite or MySQL won't understand NEXTVAL() .
+1
> And the list can go on and on and on and on ...
> As long as the database API don't "stupidify" the API so remove the need
> of writing SQL statements yourself, you need to really do a lot of
> careful research and testing among all database types you want to
> support - and only use features which works identical for all types. Or
> else you need to add a wrapper layer adopting queries depending on the
> backend database.
> SQLalchemy [1] does such "stupidifying" work. But it makes a lot of
> simple SQL commands more complicated if you know SQL very well. Hence
> my term "stupidifying". But it's probably the safest path. However, I
> don't know if SQLalchemy or similar modules are available to other
> languages than Python.
> [1] <http://www.sqlalchemy.org/>
+1 SQLalchemy is a *very* nice package. Any modern application *not*
using an ORM should, IMNSHO, have a very good justification for not
doing so [and that reason is usually bogus]. ORMs provide more than
just database abstraction but session management, result-set caching,
and protection from issues such as SQL injection.
There are ORMs for just about every language/platform: Hibernate (Java),
NHibernate (.NET), LINQ (.NET), RDO (PHP), Rose (Perl).... Quality
varies but just about anything is superior to embedding literal SQL into
an application.
> >> But I think the real point of this thread is that perl isn't bad, bad
> >> programmers (sorry, "developers") will write bad code in any language.
> > That may be someone's point. Mine is that a lot of good code has
> > already been written and is easily available. Use it instead of writing
> > your own bad code. And this is especially true for perl and java with a
> > little bit of overlap in the places you might use them. Groovy sort of
> > increases that overlap.
> To reuse other libraries/modules/extensions is *almost* always a good
> idea, no matter which language you use. At least if that
> library/module/extension is used by many and have a good development
> trend and few annoying bugs. But sometimes, such an approach makes life
> much more difficult than it needs to be to solve a single task.
> F.ex ... What if I have a C program and need a /very simple/ XML output,
> which is rather static. One simple solution is:
>
> printf("<?xml version=\"1.0\"?>\n"
> "<mydata><sender>%s</sender><msg>%s</msg></mydata>\n",
> sender, message);
>
> How many of you would use, say libxml2 to do the same job?
>
> xmlDoc *doc;
> xmlNode *root;
>
> doc = xmlNewDoc((xmlChar *)"1.0");
> root = xmlNewNode(NULL, (xmlChar *)"mydata");
> xmlDocSetRootElement(doc, root);
>
> xmlNewTextChild(root, NULL,
> (xmlChar *) "sender", (xmlChar *) sender);
> xmlNewTextChild(root, NULL,
> (xmlChar *) "msg", (xmlChar *) message);
> xmlSaveFile("-", doc);
> xmlFreeDoc(doc);
> (I avoided using scripting languages in this example on purpose, to
> avoid another Python/Perl/PHP/my-favourite-language discussion)
> Both are valid solutions and produce exactly the same result. But using
> the external library in this case is actually more error prone. If you
> forget xmlFreeDoc(), this little application leaks memory. There are no
> checks for NULL pointers, causing a segmentation fault. While the
> single printf() line would just print "(null)" instead and not crash.
> Sometimes the latter is preferred and acceptable, but a segfault is
> almost never acceptable.
> But the printf() solution also have a few other nasty gotchas which
> libxml2 will handle gracefully. Imagine if the message string contains
> HTML data, or just a single ampersand. However, sometimes your program
> will just dump out numbers, and then suddenly printf() is just as good
> as the libxml2.
+1. I'd almost always advocate solution#2. "Simple" routines rarely
stay that way and XML is literred with gotchas [escaped characters,
encoding, namespaces] that I have seen detonate two many times. libxml2
will, potentially, raise errors, and more descriptive errors, earlier in
the process of doing something stupid.
> So there are times when using external libraries/modules/extensions are
> completely overkill. And there are times when doing it yourself is task
> too big. Most good and skilled developers usually see where this border
> line goes. The rest of the developers just hack something together and
> provides something which usually works very fine and that you don't need
> to read the code afterwards.
The old saying about stability and quality: getting to 90% is easy,
that last 10% is really hard.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
