Slashdot Mirror
Exploring Active Record
An anonymous reader writes "Everyone knows that no programming language is a perfect fit for every job. This article launches a 'new series by Bruce Tate that looks at ways other languages solve major problems and what those solutions mean to Java developers. He first explores Active Record, the persistence engine behind Ruby on Rails.'"
By looking at Active Record Java developers can be happy and thankful they have a language taking good advantage of Unicode, unlike Ruby which treats users of non-ASCII alphabets (the overwhelming majority of people on Earth) as second-class citizens thanks to poor Unicode support.
I've volunteered to create a recipe-wiki-site-thing for a friend, and coming from a background in C and SQL there was just too steep a curve to map a procedural train of thought and pre-planned SQL onto the Rails way of doing things. I already created the database schema, wrote all the SQL to get the information I want, have a lot of HTML written for the general template, and was looking at abandoning much of it for controllers, models, automagic foreign key relationships, automagic methods popping out of thin air.. I wanted more control I guess.
So I've done most of the site in PHP instead. Direct, to the point, fast enough (though I'm thinking about a rewrite in C for a pure CGI/FastCGI binary), a minimum of automagic hand-holding - just start each page with sanity checking, authorization, the SQL the page needs and nothing more, and then format the output. No wondering how many hundred methods have been created that I don't know about, what happens when a record is deleted/updated (I'll let the database handle null/ignore/cascade thankyou) or whatever else Rails is doing behind my back.
I'm a C guy - I don't like things being done that I don't explicitly ask for. I want init() functions. I want implicit declarations. Heck I don't even like C++ for fogging-over-functionality with inheritance, virtual functions and overloading.
Ranting aside, I can see how Rails would mesh with a lot of people. But it's definitely not for me, and I guess (hope) a few other nutjobs around here.
Don't Hate, Gestate
People, and usually not developers, are still caught up in the idea of a programming language instead of the concept of applying an API or SDK to a task. My favorite example of this is the often held C++, C#, Visual Basic debate -- everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.
A politician giving an address in German instead of French is not more effective as his points will still remain the same. The language isn't the tool, the intention is the tool.
I like rails, but the poor apache integration sucks.
But ActiveRecord is awesome. Most of us build databases that work like objects already.. so an object oriented interface to your database is very easy to use and maintain.
Kind of ironic, really, given that Ruby actually comes from a country that uses a non-ASCII alphabet... well, not really an alphabet at all, actually.
Everyone knows that no programming language is a perfect fit for every job.
I program in raw machine code. It's a perfect fit for every job, every time!
-William Brendel
Here, we simply drag and drop then program the logic behind all those widgets we've dragged onto the form. I also looked for something in relation to Python but could not find anything! I taught VB myself using this method. Current IDEs I have looked at make things confusing. Am I looking for what does not exist? Hope not!
This "let's use all-new terminology and claim we have something new" stuff is annoying. Especially for what are, really, rather minor improvements.
eh?
You want to port it to the embedded 6502 in your special elite gizmo device.
everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.
.NET development house. You may not understand why C# is better for you than C++, your productivity may not increase, but the fact that you have switched means that your software will ultimately still cause fewer problems.
The differences between C++, C#, and VisualBasic are far deeper than syntactic. C#, for example, guarantees fault isolation, while C++ does not. C# has full reflection, while C++ does not. Programmer productivity in different languages can be orders of magnitude different.
Of course, most working programmers have the same superficial view of programming languages as you do and will make the same glib and ill-informed analogies to natural languages that you did. That's why people keep choosing C and C++, believing the differences to other languages to be merely syntactic, and then producing code that crashes, silently mangles data, and has gaping security holes.
Fortunately, the herd mentality is driving even people who don't know what they are doing away from C/C++. Even your own company bills itself as a
I have to give a shout-out to Ruby on Rails and database handling - specifically for the new developer. I've seen clients of mine (whom I consult and help deploy Rails apps) new to OO latch on to ActiveRecord very quickly, and the rapidly growing support (and marketing!) for the Rails community is promising for its long-term success.
Kudos to Yukihiro, David, Dave, Thomas, and the hundreds of others who have put together Ruby and the Rails framework to help developers grow the Web 2.0.
~William
www.RailsHosting.org
I'm amazed, a whole article by Bruce and not a single anecdote about kayaking. His writing is improving. :-)
Being bitter is drinking poison and hoping someone else will die
I recently wrote two applications that included a registration form, validation checks, sending email with a URL to click to confirm the registration and finalizing the registration.
I wrote the first one in Java and the second one with Ruby On Rails, to learn the language and experiment with the framework. The Rails application needed half as much time to be coded than the Java one, despite being totally new to Ruby and to Rails.
The merit goes almost entirely to ActiveRecord and expecially to the validation feature.
Another time saver is Ruby's being interpreted instead of compiled. That saves a few time at every change to the code, even if strong type checking at compile time would have occasionally saved me a lot of time. It's difficult to assess if I gained or lost time.
What I'm looking forward to now is a good ActiveRecord implementation for Java because Rails is great but Ruby's syntax is really appalling. Even Perl (admittedly one of my languages of choice) looks more consistent. On the other side, halving development time is something that tempts me a lot. Java on Rails would be great.
I've been playing around with Rails and AR quite a bit lately, and it has changed the way I think about programming in many (positive) ways. I come from a heavy Java / J2EE background (do that for a living, serverside systems), and Ruby + Rails is a breath of fresh air. Ruby is simply a wonderful language, there is something very "zen" about it, and Rails is inspired. Sure, it builds on a lot of old concepts, but the brilliance is where it leverages the power of the Ruby language to do things in very efficient and nice ways.
Yes, there is a lot of "black automagic" involved in Rails. It's where the power is, and you can override pretty much everything is you want to. If you're uncomfortable with magic stuff happening behind the scenes and don't want to learn Ruby so you really understand that magic, Rails might not be for you.
I'd claim that pretty much every serious programmer (VB scripters don't count :) should learn Ruby, at least the basics. It might not become your new favorite language (like it has for me), but it will give you a fresh new perspective on how to code stuff.
Ruby does have a few downsides:
(there are probably more, but I'm still only learning the language)
As for Rails, well, again there are downsides. Nothing is perfect.
So: it's not a silver bullet. Nothing is. But for a large majority of the modern-day web app use cases, it's very nice, productive and, well, elegant. It lets you to do quick prototypes and keep your code clean, you don't end up with the insecure and ugly mess most PHP apps end up being.
The current engine's something like a decade old, so it's hardly surprising. Ruby 2 is supposed to greatly improve support for Unicode, along with just about everything else.
What a revolutionary insight of a Java-follower! Congratulation, when looking at all these language flamewars, its extra ordinary that anybody can mention this and even be published by a company which bases their SW business on Java.
... (not enough knowlegde to make recommendations)
I'd like to give Bruce Tate or IBM some tips in which direction they might venture to get more insight:
- Web-Clients: HTML + Javascript with the Dojo toolkit (http://dojotoolkit.org/)
- Web-Servers: PHP/Perl/Ruby/..., whatever you like
- Binary applications: C++ with the wxWidgets framework (http://www.wxwidgets.org/)
- Database: SQL with
There are probably many more areas with recomendations but not from me, so just add your own. But think there isn't a perfect language for everthing so it should be now clear that one needs a multi language strategy to become or stay successful.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
What turns me off is forcing you to store all your data persistence into SQL and relational tables, when it is clearly a hierarchy of objects. Why does everyone think they have to do that? The software would function much more simply and the data would typically work better without it.
Maybe it's okay with things like EUC-JP and SHIFT-JIS but not okay with Unicode... who knows, I've put off reading that part of the book for ages.
Karma: It's all a bunch of tree-huggin' hippy crap!
Java though, treats people who want to use UTF-32 as second-class citizens. It's perverse too... we were all taught in University that Java supported Unicode, and then it was only in the real world where we discovered that it didn't support things like surrogate pairs. And don't try to tell me that 16 bits is enough bits to store every character you'll ever want to display or print.
Karma: It's all a bunch of tree-huggin' hippy crap!
I'm pretty sure it does in fact use one of those sort of schemes, which have been in common use in Japan for much longer than Unicode has existed. I'm not certain though, as my grasp of Japanese is far too tenuous to worry about being able to type it. :)
"Hahaha! You amateurs! How does your pathetic toy deal with redundant HA database clusters in a real-time mission-critical enterprise environment with a 5-nines uptime guarantee? Come back when you've grown up!!"
Rails is scalable, but not in an interesting fashion at all. You want more processing power, you run more instances. Where's the fun in that? I love it in Java land, where creating something scalable inevitably means exciting things like building a single JVM that runs on multiple machines, or wrapping things in five layers of EJB so that they can work across multiple machines.
Karma: It's all a bunch of tree-huggin' hippy crap!
I've recently been writing a project with Rails, using MySQL as the backend. Supporting UTF-8 has been no problem at all. UCS-2 support may well be lacking, but it's certainly not like you can't support people with non-ASCII alphabets.
PenguiNet: the (shareware) Windows SSH client
Java though, treats people who want to use UTF-32 as second-class citizens.
Java has support for Unicode 4 since Java 5, released september 2004.
Being bitter is drinking poison and hoping someone else will die
What turns me off is forcing you to store all your data persistence into SQL and relational tables, when it is clearly a hierarchy of objects. Why does everyone think they have to do that? The software would function much more simply and the data would typically work better without it.
It is great to see that developes are finally beginning to see the downsides of Rails!
The thing is, not everyone does think they have to do that! There are perfectly good high-performance ORM systems that do allow you to work with a hierarchy of objects and use rich but portable query languages - examples are Hibernate, JDO and the soon-to-be released JPA (Java Persistence Architecture).
They are as DRY (don't repeat yourself) as Rails, as with quality implementations you can automatically generate schemas from objects, or get object hierarchies generated from schemas, and they don't have to rely on endless configuration files (you can define minimal relational information as annotations in your objects).
Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability. You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability, the ability to do this means you get high-quality SQL largely automatically.
Unlike Rails, they work extremely well with both legacy schemas and schemas that are shared with other applications a developers.
Unlike Rails, some of these APIs (JDO) don't restrict you to relational systems - you can persist just as easily to things like object databases, SOAP services, LDAP, text files, filesystems etc., without changing a single line of code, and all the while using a rich query language!
These products and APIs are available right now, have open source implementations and have been used successfully by a very large number of developers for years.
My view is that they make Rails look primitive.
Yes, Ruby and it's author have an interesting attitude to string representation in general and Unicode in particular. It's partly what inspired me to write this:
Psychology of Unicode in Japan
It's really been a very interesting struggle between people's psychological and I.T. needs -- a struggle that's pretty well over now, but has left behind things like Ruby's way of doing things.
Whence? Hence. Whither? Thither.
Well lets say it that way, I have been using hibernate for quite a while and it has a lots of quirks, the most annoying aspects of it, for many is: a) many to many mappings which simply need more documentation, the best way to do is is to enforce surrogates on the many to many tables otherwise you will often run into implicit clashes via compound keying (rails already enforces it, hibernate does not, it is not documented but after many hours of trying to fix this problem on a compound key I came to the conclusion there is no sane other way to handle it)
b) The whole locking, merge save, update, persist api is a huge mess, which was carried over to a big degree into the whole jpa, partially also caused by a huge lack of documentation in exactly this critical area. (90% of all problems regarding saving usually circle around the lock persistence functions and many to many resolution)
Having to juggle with lazy non lazy objects, with merge, save, update, lock, persist wich all do almost the same but not exactly the same, with referencing issues on many to many relationships etc... Is nothing I would call a walk in the park either.
I was at a conference a while ago where one of the people hosting the conferences said, that one thing many frameworks simply have lost is the KISS principle, and the guy clearly said, the perfect example is Hibernate where someone has to be an expert in it to be able to handle it. And Hibernate is considered to be the one of the easier ones in the java world. And no this guy knew what he was talking about, I have used hibernate very often and I agree with him.
JPA, Hibernate etc... are very powerful apis, but they are way to complex for a RAD approach and they all have huge areas where they need to be cleaned up instead of being carried over to the next API. The biggest one of them IMHO are the areas mentioned.
JPA, Hibernate etc... are very powerful apis, but they are way to complex for a RAD approach and they all have huge areas where they need to be cleaned up instead of being carried over to the next API. The biggest one of them IMHO are the areas mentioned.
Good post, but I would disagree with some points. I don't think Hibernate is the easiest API - I far prefer JDO. Secondly, you don't have to use all that locking or use of lazy objects - you can use it in a very simple manner. The use of those features is for optimisation. Finally, if you want great documentation, use something other than Hibernate - JPOX and Kodo are JDO implementations with superb documentation.
No matter what some of the issues are, I don't think anyone can deny that the Java approaches have far more power and flexibility than Rails, if you want to move beyond simple RAD tasks.
Everyone does NOT KNOW that no programming language is a perfect fit for every job. I am so sick of this truism that is not true. There are plenty of great languages that work well on any job. The problem is the implementations and the runtime environments. If C++ ran in a web page in a browser, who would need javascript, for anything, ever? I'm not advocating for C++, if you like lisp the same would be true if it were just available to you when and where you were coding. It is mono-think implementation of each language that shoehorns it into only one piece of footware.
You bring up a point here with using something else, until recently Hibernate was the only OSS based implementation of an ORM system usable and coming close to being a standard and having good tools, now that JPA is out, we have finally a good number of them all based on JPA:
Hibernate, KODO JPA, Toplink JPA all OSS based on various licenses. Due to the issues mentioned I will probably move away from Hibernate towards something else.
The main problem with Kodo simply used to be the price which was way too high for small developments, and still is if you need KODO JDA, but the JPA implementations are there now or will be there soon and usuable for a budget.
Apart from its inherent inadequacies compared to 'real' databases, what's the big disaster area about Access? What do people do horribly wrong, and what's the wonderfully better approach?
Real Daleks don't climb stairs - they level the building.
Due to the issues mentioned I will probably move away from Hibernate towards something else.
:)
I use a JDO product (Kodo) for very large transactions (hundreds of thousands of records), and it works very well and fast. Hibernate was, according to the developers, not intended for this sort of use - which I interpreted as a coded way of saying 'it is too hard to run write our stuff to run efficiently like that and we aren't bothering'
Hibernate is extremely popular, but, in opinion, far from the best. The Kodo OSS implementation of JPA is something I am eagerly awaiting!
Well KODO is considered to be the best persistence layer for java around, I am glad that Bea decided to opensource the KODO EJB3/JPA layer under an Apache license. And I agree Hibernate is subotimal, there are issues with performance in certain areas, there are issues with mass data, and the whole many to many handly in combination with some of the Hibernate core people (not Gavin King he always is nice) in the JBoss forums gives it the rest. I cannot await to move away from Hibernate towards EJB3 JPA based on Kodo.
accordingly, things i dislike about active record:
1) it seems to mirror tables pretty directly;
2) i don't think the objects you work with in code should know how they are stored - this means they don't inherit or mix-in any database code at all. there should be separate classes that handle this.
this holds for other languages too, of course. python in this case:a Ticket may consist of data aggregated from several tables; the client code doesn't care about that. the TicketStorage class worries about storage.
now, inside TicketStorage, you might use your ORM of choice, or access the DB directly, or whatever. the point is, the public methods of TicketStorage draw the line in the sand between the code using the Ticket objects and anything storage-related.
that's my preference from a design perspective, anyway.
free software, open standards, open file formats, no software patents.
People just getting in to rails and ruby are not likely to have done more than scratched the surface of what ActiveRecord is capable of. This is a great introductory article, but I'm curious just how far you can push ActiveRecord.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
In fact, rather then ASCII Ruby was designed with SHIFT-JIS, a sort of japanese ascii.
autopr0n is like, down and stuff.
Well, java is older then utf32, but whatever.
autopr0n is like, down and stuff.
Fascinating write up. I had no idea there was such a debate even going on. Excellent work.
" Everyone knows that no programming language is a perfect fit for every job."
I truly, deeply wish this was the case.
The ActiveRecord pattern is NOT new, and it won't scale out past a few dozen tables. Never has, there is a REASON that it is not a successful pattern in ALL languages. For TOY applications, it might be fine, but for say something like an ERP system with thousands of tables, it just won't scale out performance or maintanence wise, never will.
How, precisely, does Ruby not support Unicode? What can't you do in Ruby wrt Unicode that you want to do?
"Everyone knows that no programming language is a perfect fit for every job."
> Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability.
> You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to
> high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability,
> the ability to do this means you get high-quality SQL largely automatically.
Great, "rich query languages" that wrap richer query languages. That are highly portable across databases, but themselves are not portable across application layers (do *any* reporting tools support them? is there an ANSI standard for ORMs?)
When a developer needs to run adhoc queries in order to diagnose problems with data in a database, to test impacts of schema migration, etc - do they write SQL or application code? Keep in mind that these are not likely to be simplistic queries...
If you want all the flexibility of SQL, does it make sense to completely wrap one language in another - when you really don't get 100% portability? Or is this really just a solution that slightly simplifies things for 50% of the problem space - for those developers who refuse to learn SQL?
Seriously SQL isn't the greatest language in the world, but I have a hard time understanding why anyone that works with database applications can't handle complex queries. It's like someone working on the linux command line that refuses to learn bash. Or like a web developer that refuses to learn HTML and just uses FrontPage instead.
And aside from the "When in Rome" argument, consider the benefits of learning a data-oriented approach to working with data. SQL is more different from java, python or ruby than lisp is. One of the best things a programmer can do is to to become fluent in multiple different types of languages. Compare SQL's set-based logic to lisp or python. Learn to think of data in terms of sets and aggregates instead of just one row at a time. Until you do that you'll never understand reporting, which is really about how to answer basic business questions. But maybe that's why we've never seen a powerful reporting tool come out of the java community?
thread.article(parent.id).getPoster() == +1 Funny!
I'm not sure I get your neutral tone in that document. Even though the Unicode standard has certain minor flaws and is not entirely perfect for Japanese needs, do you really believe the arguments put forth by the Japanese nationalists at all justify the total rejection of Unicode in favor of some incompatible local standard? To me this seems a very clear case of politics getting in the way of sound technical decisions.
Great, "rich query languages" that wrap richer query languages.
No, in some cases the portable query language is more featured that the language it wraps. JDOQL implementations can provide rich querying even on systems with no built-in query language (like filesystem storage).
That are highly portable across databases, but themselves are not portable across application layers (do *any* reporting tools support them?
Of course they are. There are reporting tools like JasperReports that can use Hibernate Query Language directly.
is there an ANSI standard for ORMs?)
There are JCP standards for Java ORMs that are fully supported by many vendors.
Is there any modern standard for SQL that is fully supported by any vendor? No.
When a developer needs to run adhoc queries in order to diagnose problems with data in a database, to test impacts of schema migration, etc - do they write SQL or application code? Keep in mind that these are not likely to be simplistic queries...
They can use either. Why on Earth are you assuming that these portable query languages are restricted to simplistic queries?
Seriously SQL isn't the greatest language in the world, but I have a hard time understanding why anyone that works with database applications can't handle complex queries.
You are missing the point. Of course they can handle complex queries. What they don't want to have to do is to re-implement thousands of those complex queries in order to migrate to another database product.
It's like someone working on the linux command line that refuses to learn bash. Or like a web developer that refuses to learn HTML and just uses FrontPage instead.
No. The portable query languages aren't less rich than SQL. They are simply portable. That is the big difference.
And aside from the "When in Rome" argument, consider the benefits of learning a data-oriented approach to working with data.
Who says this isn't the case?
SQL is more different from java, python or ruby than lisp is. One of the best things a programmer can do is to to become fluent in multiple different types of languages. Compare SQL's set-based logic to lisp or python. Learn to think of data in terms of sets and aggregates instead of just one row at a time. Until you do that you'll never understand reporting, which is really about how to answer basic business questions.
This is completely irrelevant. Portable query systems in Java are data-oriented, and work with sets and aggregates just like SQL. The difference is that they are 100% portable.
But maybe that's why we've never seen a powerful reporting tool come out of the java community?
No - you have never seen a powerful reporting tool. This does not mean there aren't any. There are plenty.
JasperReports is a good one.
I think posters really need to do some more research before commenting on matters like this - I keep reading posts like this that bear little relation to reality.
The ActiveRecord pattern is NOT new, and it won't scale out past a few dozen tables.
How many applications out there have more than a few dozen tables? I'd have serious concerns with a system that had a single application, with a single database, comprising of hundreds of tables. In reality such systems are quite rare--for every massive ERP implementation there are hundreds or thousands of smaller applications where Ruby on Rails' Active Record model would work very well.
For TOY applications, it might be fine, but for say something like an ERP system with thousands of tables, it just won't scale out performance or maintanence wise, never will.
There are other approaches to system design as well--how about applying a modular "UNIX philosophy" to an enterprise system with several
distinctly defined "TOY applications" each dealing with a smaller number of tables, all loosely coupled together? Even big, old accounting systems are broken into "modules" after all (which historically are more tightly coupled with the main system but still deal solely with a smaller subset of tables/files).
I, for one, like "toy applications". I don't think I've ever heard a developer get real enthusiastic about implementing or maintaining an ERP system--not the way a manager or marketing person does anyways. Come to think of it I don't know a lot of enthusiastic end users of such systems either. Perhaps a mega-corporation saves a lot of time and makes its business more efficient with its mega-ERP systems, however, feeding and caring of that beast is still tedious and annoying--it's just less tedious, annoying and expensive than dealing with mistakes, redundancies and general idiocy an enterprise has to deal with in the absence of a good business management system.
One thing is certain: there are different tools suited to different jobs, and Ruby on Rails/Active Record is best suited to smaller-sized applications where everything is developed from the ground up. Saying it lacks legitimacy because it cannoy scale to handle apps of gigantic proportions or properly interface to complicated, arcane legacy systems (ALL contemporary ERP systems in production use today are "legacy systems" IMHO) is like saying the familiar operator interface of an automobile is a failure because it cannot "scale out" to handle "real" vehicles like high-speed super-trains, jumbo jets or spacecraft. Over 90% of us never need to scale out past four wheels going up to 125km/h and carrying a couple of passengers.
And don't get me started on performance: Java was widely criticised for its performance, as were PHP and Perl for being interpreted and "slow"...however the use of all of those in very high-volume, demanding production systems. The hardware is out there to handle it now, and I've never heard people complain that Rails or Active Record are way too slow to handle the tasks asigned to them.
That stuff sounds really interesting. Do you have links for some of the research? I've heard of hibernate, but not the JPA. Is that going to be part of the standard JRE? I hate having my code rely on goofy 3rd party add-ons.
autopr0n is like, down and stuff.
Well, what are you storing in your database? A simple hierarchy is captured pretty well with a standard, relational database with foreign keys. If you think of trees as a subset of graphs, and a relational database as a graph, you can see that any tree can be encoded as a relational database, you just need a table for every separate type of object. Going further, you can also see that any and all graphs can be expressed as a relational database, just have a "node" table and an "edge" table. (and probably an attributes table for attributes of nodes and edges, to store your data). In memory, you may end up with something much more complicated then a tree, with lots of back links and whatnot. That can't be encoded as a tree, but it can be encoded as a relational database. (I'd love to see someone come up with a graph query language. Get ready for NP-complete queries!) --- Personally, I think relational databases are great. Not because they're 'the way data is' but because they require the programmer to actually sit down and *think* about the data they are saving, and make something that's comprehensible. On the other hand, if they can just save whatever and have it persist, then you might end up with god knows what in your files. Different programs, and even worse: different versions of the same programs might not be able to read the tree properly. On the other hand, yes, it would be much easier to write the code in the first place if you didn't have to write a DAL to convert your objects to queries and vice-versa.
autopr0n is like, down and stuff.
Ouch.
There were linebrakes in that when I hit the "submit" button...
autopr0n is like, down and stuff.
>> Great, "rich query languages" that wrap richer query languages.
> No, in some cases the portable query language is more featured that the language it wraps. JDOQL
> implementations can provide rich querying even on systems with no built-in query language (like filesystem storage).
That makes sense - and does sound somewhat valuable.
> Is there any modern standard for SQL that is fully supported by any vendor? No.
The ANSI SQL standard has levels of compliance. For typical queries on typical databases (not perhaps mysql which often disregards ANSI) the standard is well supported.
> What they don't want to have to do is to re-implement thousands of those complex queries in order to migrate to another database product.
Hmm, having perform many ports between database products I can honestly say that I've never bumped into this problem outside of SQL Server/Sybase stored procedure insanity. The most often case is 10% of your queries might require a tweak. 1% might require a rewrite. So, to avoid this you wrap the entire language in an entirely new language? That itself can't support 100% of the features of the first, and isn't usable by everything that supports the first?
>>But maybe that's why we've never seen a powerful reporting tool come out of the java community?
> No - you have never seen a powerful reporting tool. This does not mean there aren't any. There are plenty.
> JasperReports is a good one.
After doing reporting for twenty years across many projects I've seen most reporting tools out there. If you consider JasperReports powerful then you really don't understand reporting. It's just a report painter - not much different technology than we were using in 1989, and that Crystal Reports has provided for 10+ years. It's the wrong way to deliver reporting, rather than use metadata-driven reporting that can automatically allow the users to wander through an n-dimensional cube of data, the programmer laboriously creates individual reports. Yuck.
> I think posters really need to do some more research before commenting on matters like this
> - I keep reading posts like this that bear little relation to reality.
Hmm, I think people should actually learn how to use databases before coming up with ingenious work-arounds like:
- Object Oriented Databases - that can't handle sequential scans, reporting, searching.
- Hierarchical Databases - reinventions of technology thrown away in the 80s.
- XML as a database - completely misses concepts of ACID, concurrent users, sequential scanning
- wrappers to help programmers avoid learning the lingua franca of databases (SQL)
Sorry to be so negative towards your point, but I've been on multiple J2EE projects where programmers adopted some brilliant idea like OODBMS, container managed pesistence, or sometimes just EJBs - only to discover later that the way that the java community thinks about data only covers about 50% of its needs.
Remember that a large part of the resistance that people have to learning a computer language has to do with how difficult it was to learn the last one.
When it's difficult to learn to do something, one doesn't want to write off that investment. Do you still use a qwerty keyboard? So do I. But I'm well aware that other keyboards are easier and faster. If you press me, I'm likely to make up an excuse, but the real answer is I don't want to invest the time involved in relearning touch typing.
I think we've pushed this "anyone can grow up to be president" thing too far.
After doing reporting for twenty years across many projects I've seen most reporting tools out there. If you consider JasperReports powerful then you really don't understand reporting.
The poster was asking to hear about a product that allowed use of an ORM portable query language; that is the reason for mentioning JasperReports.
Hmm, having perform many ports between database products I can honestly say that I've never bumped into this problem outside of SQL Server/Sybase stored procedure insanity. The most often case is 10% of your queries might require a tweak. 1% might require a rewrite.
Hmm, well, I deal with this on a daily basis. It is nothing like you describe. I am involved in porting projects that take months, and I know many others who have had to deal with the same issues.
So, to avoid this you wrap the entire language in an entirely new language? That itself can't support 100% of the features of the first, and isn't usable by everything that supports the first?
The languages are standardised, and they can support all features.
Hmm, I think people should actually learn how to use databases before coming up with ingenious work-arounds like:
- Object Oriented Databases - that can't handle sequential scans, reporting, searching.
- Hierarchical Databases - reinventions of technology thrown away in the 80s.
- XML as a database - completely misses concepts of ACID, concurrent users, sequential scanning
- wrappers to help programmers avoid learning the lingua franca of databases (SQL)
I am not talking about these! I am not talking about OOP, hierarchical databases, or XML.
I am talking about SQL-like languages (that DO require you to understand SQL and its concepts - this is, of course, essential) but allow true effective portability.
Sorry to be so negative towards your point, but I've been on multiple J2EE projects where programmers adopted some brilliant idea like OODBMS, container managed pesistence, or sometimes just EJBs - only to discover later that the way that the java community thinks about data only covers about 50% of its needs.
This is why I was talking about more research needed by posters, as if you think that modern ORMs force any of the above solutions, you are way out of date. I am not talking about OODBMS or container managed persistence! I am talking about rich, lightweight object/relational mapping systems that allow full use of the underlying databases.
"I already created the database schema, wrote all the SQL to get the information I want, have a lot of HTML written for the general template, and was looking at abandoning much of it for controllers, models, automagic foreign key relationships, automagic methods popping out of thin air.. I wanted more control I guess."
So, you wrote most of the app, then started looking at frameworks, then you were dissapointed when the framework didn't mesh with the work you'd already done.
I'm not looking to be the great defender of rails, but I'm very surprised that your post was modded +4, Interesting. Rails is meant to eliminate a lot of the work you had already done (mostly the SQL stuff). Their mantra is convention over configuration. If you prefer control of course rails isn't going to be for you.
That's kind of funny since I've written programs that parse Japanese text using Ruby and I have actually switched the code and database between EUC, SJIS, and UTF-8 with no problems. As far as I know, you can't use UCS-2, but UCS-2 is deprecated anyway since you can't encode the whole Unicode space in it anyway.
My other first post is car post.
don't try to tell me that 16 bits is enough bits to store every character you'll ever want to display or print.
Okay, I won't, but can you tell me why I would need more than 16 bits to store a single character ? Why the hell do we need so many characters in the world ? Are there so many ways to say "Hello" that we need millions of characters to communicate with our neighbors ? I'm not saying everyone should speak english (I'm french myself), but eventually the various dialects will condense into more portable languages.
Maybe in a few decades, maybe in a century.. sooner or later the concept of unity will be more than just words on the back of a student flyer, and we will want to understand others no matter what land they hail from. Why should a computer understand 4 billion characters when humans only use a few hundred at best, for most of us just a few dozen.
-Billco, Fnarg.com
You Unicode fans might like to know that Japanese in Unicode is not done well, it leaves much to be desired for computation/sorting/searching in the three character/pictograph sets in use by average literate Japanese person. Other encodings are prefered and more useful
Okay, I won't, but can you tell me why I would need more than 16 bits to store a single character ? Why the hell do we need so many characters in the world ? Are there so many ways to say "Hello" that we need millions of characters to communicate with our neighbors ? I'm not saying everyone should speak english (I'm french myself), but eventually the various dialects will condense into more portable languages.
Of course. For example, we don't need to runic characters in real life, however if you wanted to write a textbook on Anglo-Saxon linguistics, you'd be up shit creek if those characters weren't in there. Same goes for any given language.
Karma: It's all a bunch of tree-huggin' hippy crap!
You're right, that the language itself is not the only thing that matters. Extra libraries to work with makes life much more pleasant.
But what's under the hood of that do_something_with_file_data? In this fairly trivial example, there's not much difference between a do_something_with_file_data in C versus Perl.
Nice code examples deleted 'cause of /. stupid lameness filters inserting random spaces, even when I had spaces nearby. GRRRR! Suffice to say both were functionally equivalent and of about the same length: about 8 lines for reasonably readable code that output reasonable, though not strictly standards-compliant, HTML.
For more complicated web work, however, I would still maintain that there are better languages than C (and Perl for that matter) to be doing the work. I'm not for a moment suggesting that I can replace what would take me a year in C with a day's work in Python (excepting the library issues), but I think that the so-called "scripting languages" are faster to develop many types of applications even without the library advantages they have.
Execution speed arguments are less a function of the language itself than a function of those environments the languages themselves typically operate in. There are python, perl and Java compilers and I'm sure somebody has made a C interpreter for some strange reason. Most applications do not need to be as efficient as possible by virtue of the fact that a lot of them sit in an idle state most of the time anyway. There are notable exceptions (scientific computing, games, etc.), but there you're going to be writing as close to the hardware as you dare and maybe even C is too much of a luxury and you'll have to write assembly.
I agree that a language choice, given appropriate and featurewise compatible libraries existing for the task at hand, isn't usually going to make a many orders of magnitude difference in development speed. I do still contend however that appropriate languages to the task at hand can save you a decent slice of project time. My gut instinct would be to say the average would be around 20 to 30. Not massive, but noticeable on the bottom line. Sometimes that choice will even be C. And some things still need the raw power of C. Not bagging on C at all, here! It was the fifth language* I learned, after TRS-80 Extended Color Basic, 6809 Assembly IBM 360 Assembly, and Pascal. Of those five, it's the only one I still use at all, much less remember, and I still love hacking on it.
I will concede that my gut is not (perhaps) as accurate as a study, but my only point was to say I will still trust my experience over a random stranger on Slashdot waving "studies" around without any reference to what they're referring to.
*- FORTH was sixth. I've forgotten it, too.
It's called "objectivity". He should be applauded, not condemned, for writing something so balanced. You came to the conclusion that the Japanese are being unnecessarily stubborn regarding Unicode. So did I. I think that says something given the fact that neither of us believe he took a stance on way or the other.
Yes, I'm not criticizing him about it especially. I was mostly trying to poke him into giving his opinion, since he seems better-informed than I am.
Okay good point, but why not just use a dedicated runic font for that specific purpose ? We already have those, they're just poorly supported in general-purpose software. Why the hell would general-purpose applications need to know foreign charsets ? Just because a handful of people want a feature does not mean the whole world should change the way they write code just to accomodate that minority. Unicode is such a big deal yet I can't justify the need in my daily computing tasks. Even if I spoke a foreign language that requires non-latin characters, I would simply use that specific font, I don't need the other 2700 languages along with it. I think it would be far easier for an application to support two or three individual charsets than 32-bit character spaces.
-Billco, Fnarg.com
Yes. About the only use for Unicode is keeping track of your Elvish and Klingon dipthongs in the same character set. 2 byte words is enough for China and Japan has their own system that works. Meanwhile, everyone uses ascii except when representing pictograph characters.
Okay good point, but why not just use a dedicated runic font for that specific purpose ?
For semantics. An application that processes text won't deal with fonts. If it did deal with fonts, it would still need a way to convert the bogus text into a real representation, and for that representation, we would use Unicode.
Karma: It's all a bunch of tree-huggin' hippy crap!
Look, you ignorant slobs, UCS-2 is incomplete due to its lack of support for real characters in one real, living language, and I'm startled if you can't guess which one!
GB-18030 is the string you want to google...
have you ever used unicode?