by Bozho | Jul 26, 2012 | Aggregated, Developer tips
The scenario is trivial – you want to generate a database schema creation script while building your application (and then execute the script on the target database) This was relatively easy with Hibernate 3, as there was the hibernate3-maven-plugin, but it is not compatible with Hibernate 4. And for every new project you should start with Hibernate 4, of course. So what to do? It’s relatively simple, but takes some time to research and test. The idea is to use the SchemaExport tool. But it’s a bit tricky, because it only supports native Hibernate configuration and not JPA. First, you create a command-line application that handles the export. Note that Ejb3Configuration is deprecated, but it is deprecated for external use – hibernate are using it internally quite a lot. So it is a properly working class: @SuppressWarnings("deprecation") public class JpaSchemaExport { public static void main(String[] args) throws IOException { execute(args[0], args[1], Boolean.parseBoolean(args[2]), Boolean.parseBoolean(args[3])); } public static void execute(String persistenceUnitName, String destination, boolean create, boolean format) { System.out.println("Starting schema export"); Ejb3Configuration cfg = new Ejb3Configuration().configure(persistenceUnitName, new Properties()); Configuration hbmcfg = cfg.getHibernateConfiguration(); SchemaExport schemaExport = new SchemaExport(hbmcfg); schemaExport.setOutputFile(destination); schemaExport.setFormat(format); schemaExport.execute(true, false, false, create); System.out.println("Schema exported to " + destination); } } Note here, that we are not directly deploying the file to the target database. (the 2nd argument to .execute is false). This is because we don’t have our database connection properties in persistence.xml – they are external. Deploying the schema file is done later in the maven build, but this is beyond the scope of this post. Then we have to just invoke this class from the maven build. I...
by Bozho | Jun 19, 2012 | Aggregated, Opinions
We are starting a new project and we have to choose the web framework. Our default choice is grails, because the team already has experience with it, but I decided to give Play! and Scala a chance. Play! has a lot of cool things for which it received many pluses in my evaluation, but in the end we decided to stick with grails. It’s not that grails is perfect and meets all the requirements, but Play! is not sufficiently better to make us switch. Anyway, here’s a list of areas where Play! failed my evaluation. Please correct me if I’ve got something wrong: template engine – UI developers were furious with the template engine used in the previous project – freemarker, because it wasn’t null-safe – it blew up each time a chain of invocations had null. Play templates use scala, and so they are not null-safe. Scala has a different approach to nulls – Option, but third party libraries and our core code will be in Java and we’d have to introduce some null-to-Option conversion, and it will get ugly. This question shows a way to handle the case, but the comments make me hesitant to use it. That’s only part of the story – with all my respect and awe for static typing, the UI layer must use a simple scripting language. EL/JSTL is a good example. It doesn’t explode if it doesn’t find some value. static assets – this is hard, and I couldn’t find anything about using Play! with a CDN or how to merge multiple assets into one file. Is there an easy way...
by Bozho | Jun 9, 2012 | Aggregated, Opinions
I just got a couple of comments on stackoverflow that the links in my answers are broken. They were all about spring answers, and it appeared spring have changed the URL structure for their documentation. I don’t know when exactly this had happened, but it has. Now, that’s a dumb thing to do if you are even a remotely popular framework/product. Especially with the existence of stackoverflow, “one does not simply change their documentation URLs”. @SpringSource did you change the URLs of the documentation, thus breaking every stackoverflow answer about spring? — Bozhidar Bozhanov (@bozhobg) June 9, 2012 This is not just about documentation of softhware products – it’s about all static resources (this is used for assets like js and css, but here I mean documentation, descriptions, etc.). People link to these things in their comments in forums, Q&A sites and bookmark them. So you should not return 404 for a page that once worked. Now, this is not possible for every page, of course. But the pages that people are most likely to link to have to remain accessible via the original URL. It lives on the internet. By the way, it is good to have /latest documentation, otherwise we will be stuck on old versions in the top google results (Java 1.4 still appears on top). Some may say “But my original URL structure was stupid”. Fair enough, then 301 to your new page. And if you don’t do 301, each time you change a URL of something “linkworthy”, consider the link rot you are causing. And if you do it, you should be like that:...
by Bozho | May 16, 2012 | Aggregated, Developer tips
You develop your site, and you are going to deploy it to production. Assuming you have a lot of traffic, you’d need to optimize your assets (javascript and css). Some of these things are also valid for images, but there’s more to be said there, so I’ll focus on css and javascript. It’s way more complicated than you’d like. Here are the steps: merge – all your javascript and css files should be merged into a single file so that the browser fires only one request. Frameworks sometimes have tags to do that, otherwise you have to merge them in your build and then use the merged version. minify – before or after getting the files merged you need minify them. That is, get rid of all useless symbols, which make the files readable, but increase the file sizes. This normally happens when you build your application, though minification-on-the-fly-and-then-cache is also a good option version/hash – normally your assets should be cached by browsers for a long time, so when you make a change you need a good way to make the browsers refresh them. That’s why you append a version (/styles/1/main.css) which you can configure in your app, or you compute a hash of the resource and use that as automatic version. (Of course, always set a long expiry header to assets, so that they are requested only once by each user) gzip – after the files are merged and minified you should gzip them before sending them to the browser. This is handled by most servers and/or frameworks, so it sounds like an easy bit. But read...
by Bozho | May 10, 2012 | Aggregated, Opinions
I’ve seen tons of articles and comments (especially comments) that tell us how bad, crappy and wrong is the concept of ORM (object-relational mapping). Here are the usual claims, and my comments to them: “they are slow” – there is some overhead in mapping, but it is nothing serious. Chances are you will have much slower pieces of code. “they generate bad queries which hurts performance” – first, it generates better queries than the regular developer would write, and second – it generates bad queries if you use bad mappings “they deprive you of control” – you are free to execute native queries “you don’t need them, plain SQL and XDBC is fine” – no, but I’ll discuss this in the next paragraph “they force you to have getters and setters which is bad” – your entities are simple value objects, and having setters/getters is fine there. More on this below database upgrade is hard – there are a lot of tools around the ORMs that make schema transition easy. Many ORMs have these tools built-in But why do you need an ORM in the first place? Assume you decided not to use one. You write your query and get the result back, in the form of a ResultSet (or whatever it looks like in the language you use). There you can access each column by its name. The result is a type unsafe map-like structure. But the rest of your system requires objects – your front-end components take objects, your service methods need objects as parameters, etc. These objects are simple value-objects, and exposing their state via getters...
Recent Comments