3 ms·

> how quickly it was becoming a major chore to change the trivialest of things This was more than likely just bad design on your part. GlassFish 3.12 support J

> how quickly it was becoming a major chore to change the trivialest of things This was more than likely just bad design on your part. GlassFish 3.12 support Java EE 6 which supports a lot of POJO based development - between your mention of abstract base classes, factories, and J2EE (which became Java EE over 8 years ago) I have to wonder if you used a lot of legacy APIs and design patterns. > Also I made the unfortunate mistake of using JavaDB/Derby as the datastore Derby is neat for an portable in-process relation db but no one in their right mind uses it for a large or high-performance db. But most db changes should be isolated to your persistence layer using Hibernate/JPA so changing database vendors shouldn't have caused a big change in your code unless you had to redesign your tables for some other reason.

Nanzikambe 13y ago
> This was more than likely just bad design on your part. Oh I won't deny that, as I mentioned, I approached the problem from a background with limited exposure to modern web technologies. Still though, lets take just one aspect, db interaction for which I used hibernate: First I create my DB structure, then create an XML mapping, then create the POJO model (replete with getters/setters) sure, most IDEs do this automagically, but experience with switching IDEs and changing versions makes me abhore IDE generated code, then hibernate's own XML config, then the utility class (I called these factories, my bad). Not to mention the prerequisites that made all this possible, glassfish, maven etc require their own configuration etc. By now I have several thousand lines of code and I've not even implemented any functionality. Time taken, no clue, but hours, lots of hours. The equivalent with Python + TornDb? Create schema, extend torndb to pull credentials from environment variables & connect to db (3 lines of code, wow), create flaskapp.py, bind path to a method, begin writing the "real" code. Lines of source, under 100. Time taken, less than an hour. > J2EE (which became Java EE over 8 years ago) I have to wonder if you used a lot of legacy APIs and design patterns. When you spend a considerable amount of time calling something by one name, despite a rename you tend to continue. Apologies for using the incorrect name, but the rest of your assumption are unfounded unless you're calling Glassfish, Hibernate, Jersey, JSF and JavaDb legacy .. > Derby is neat for an portable in-process relation db but no one in their right mind uses it for a large or high-performance db Those were precisely the reasons I chose it, the example I gave isn't large or high performance, and its pathetic at that role, I stand by my assertion. You'd be better off using serialised objects, CSV files, heck even notes scribbed on postit notes tacked to the wall than JavaDB. I say this after countless hours spent taking the platform offline to rebuild the database which grew uncontrollably despite careful use of transactions within hibernate and daily cron jobs to run SYSCS_UTIL.SYSCS_COMPRESS_TABLE
- twic 13y ago
  For the schema stuff, these days what i would do is write the objects, add the minimal set of JPA annotations (which can be as little as @Entity at the top and @Id on the ID column), then generate the DDL from that. You don't need any XML for the mapping. Sadly, you do still need a persistence.xml with the database connection details, and for some providers a list of all your entity classes (WTF). I have a build script which generates all that (amongst other things), though: https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097f86e29866b6ccd90e9663f2fd/build.gradle?at=default https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097...
  - Nanzikambe 13y ago
    Interesting! I did end up using annotations as you mention. However I chose to manage the db structure myself because early on I encountered problems when I changed data types and indexes, hibernate incombination with JavaDB dropped then recreated the structure, which is fine, but then if you want to push your changes to the live version, I had to write the SQL to port the live data into the newly created table which was a PITA given javadb can't insert into "GENERATED ALWAYS AS IDENTITY" columns, so that in turn meant more SQL to preserve referential relationship between data. I was always left feeling I did something totally wrong in that respect, so I blame myself. A part of this also stems from the way I approach building an application, I'll always spec & then create out the DB as a way of helping me visualise the model before I start doing any "real" coding. I still respect Java enormously, but I'm not at all sold on JEE application servers for anything below enterprise scale applications. And for any case where you need a quick prototype, Java definitely will not be my choice in the future.
- matt_heimer 13y ago
  Why a XML mapping file? If you don't like getters/setters no one is forcing you. A fully function JPA entity class is: @Entity public class TableName { @Id public int primaryKeyColumnName; public String someOtherColumnName; @Column(name="DESC") public String fieldThatDidNotMatchColumnName; } How the heck did you get to thousands of lines of code without even having an functionality? You can create a RESTful webservice that does basic CRUD ops to a database in just a handful of lines.... And unfortunately there are tons of legacy APIs (backwards compatibility...) available in any Java EE app server like GlassFish. Hopefully they really will start pruning things from the spec. Do you want to create a basic CRUD web service with your hip-Startupy method of choice and I'll create a Java equivalent so we can compare? I'm curious about how it would play out.

Nanzikambe 13y ago

> This was more than likely just bad design on your part. Oh I won't deny that, as I mentioned, I approached the problem from a background with limited exposure to modern web technologies. Still though, lets take just one aspect, db interaction for which I used hibernate: First I create my DB structure, then create an XML mapping, then create the POJO model (replete with getters/setters) sure, most IDEs do this automagically, but experience with switching IDEs and changing versions makes me abhore IDE generated code, then hibernate's own XML config, then the utility class (I called these factories, my bad). Not to mention the prerequisites that made all this possible, glassfish, maven etc require their own configuration etc. By now I have several thousand lines of code and I've not even implemented any functionality. Time taken, no clue, but hours, lots of hours. The equivalent with Python + TornDb? Create schema, extend torndb to pull credentials from environment variables & connect to db (3 lines of code, wow), create flaskapp.py, bind path to a method, begin writing the "real" code. Lines of source, under 100. Time taken, less than an hour. > J2EE (which became Java EE over 8 years ago) I have to wonder if you used a lot of legacy APIs and design patterns. When you spend a considerable amount of time calling something by one name, despite a rename you tend to continue. Apologies for using the incorrect name, but the rest of your assumption are unfounded unless you're calling Glassfish, Hibernate, Jersey, JSF and JavaDb legacy .. > Derby is neat for an portable in-process relation db but no one in their right mind uses it for a large or high-performance db Those were precisely the reasons I chose it, the example I gave isn't large or high performance, and its pathetic at that role, I stand by my assertion. You'd be better off using serialised objects, CSV files, heck even notes scribbed on postit notes tacked to the wall than JavaDB. I say this after countless hours spent taking the platform offline to rebuild the database which grew uncontrollably despite careful use of transactions within hibernate and daily cron jobs to run SYSCS_UTIL.SYSCS_COMPRESS_TABLE

twic 13y ago
For the schema stuff, these days what i would do is write the objects, add the minimal set of JPA annotations (which can be as little as @Entity at the top and @Id on the ID column), then generate the DDL from that. You don't need any XML for the mapping. Sadly, you do still need a persistence.xml with the database connection details, and for some providers a list of all your entity classes (WTF). I have a build script which generates all that (amongst other things), though: https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097f86e29866b6ccd90e9663f2fd/build.gradle?at=default https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097...
- Nanzikambe 13y ago
  Interesting! I did end up using annotations as you mention. However I chose to manage the db structure myself because early on I encountered problems when I changed data types and indexes, hibernate incombination with JavaDB dropped then recreated the structure, which is fine, but then if you want to push your changes to the live version, I had to write the SQL to port the live data into the newly created table which was a PITA given javadb can't insert into "GENERATED ALWAYS AS IDENTITY" columns, so that in turn meant more SQL to preserve referential relationship between data. I was always left feeling I did something totally wrong in that respect, so I blame myself. A part of this also stems from the way I approach building an application, I'll always spec & then create out the DB as a way of helping me visualise the model before I start doing any "real" coding. I still respect Java enormously, but I'm not at all sold on JEE application servers for anything below enterprise scale applications. And for any case where you need a quick prototype, Java definitely will not be my choice in the future.
matt_heimer 13y ago
Why a XML mapping file? If you don't like getters/setters no one is forcing you. A fully function JPA entity class is: @Entity public class TableName { @Id public int primaryKeyColumnName; public String someOtherColumnName; @Column(name="DESC") public String fieldThatDidNotMatchColumnName; } How the heck did you get to thousands of lines of code without even having an functionality? You can create a RESTful webservice that does basic CRUD ops to a database in just a handful of lines.... And unfortunately there are tons of legacy APIs (backwards compatibility...) available in any Java EE app server like GlassFish. Hopefully they really will start pruning things from the spec. Do you want to create a basic CRUD web service with your hip-Startupy method of choice and I'll create a Java equivalent so we can compare? I'm curious about how it would play out.