This project is hosted at
|
|
specifically here:
|
|
To download the code generator and dao you just need the latest daomedgegen.zip.
|
|
DAOMedge
This is a database access object with a code generator. It allows selections across tables, across catalogs etc. The filters are pretty powerful and if there is a gap in
the library's abilities it could be filled by using a view instead of a table. Version 10 allows for columns from multiple tables in the same result set. See documentation for any limitations.
Why daomedge? I'm glad you asked. When I started this I figured that there was a lot of DAO type libraries, and I wasn't too wrong, so called it daomedge because no one else would have called theirs that!
Basic Principles
The basic principle is that the database structure is the correct one, not the java objects. I am, at heart a DBA and database designer1.
Example Code
These are based on my test suite, I have changed what needs to be changed. They should give you an idea of how to use this library.
Unit tests are tricky when dealing with databases, particularly the C UD parts of CRUD, So these are a little more direct.
The Two Main Classes
Abstract Test Class Used in all of the test classes
Default Order By
Database Execute
Pretty Much All Selects
Integer As String
Load Connector
Multi Key
Multiple Table Selection
Updating
ByteArrayBuilder Not a part of DAOMedge, but nice.
Primes in C Not a part of DAOMedge, but it's my first from scratch complete C programme.
Factors in C Not a part of DAOMedge, but it's my second from scratch complete C programme.
Fibonacci in C Not a part of DAOMedge, but it's my third from scratch complete C programme.
Background
This is not specifically JDO nor does it conform to any DAO standards. I developed this library
as a personal project I started when, over 20 years ago, follow coders were chatting about JDO and how to implement it.
We were also talking abount Mandelbrot Sets and how to generate them. I was working in Delphi from Borland, writing a
Mandelbrot generator app in Object Pascal. I wrote version 1.0.0 of DAOMedge using a MySQL database at home, in Java JDK 1.1 (The first version with JDBC)
on an early pentium computer, running Windows 95. I was hoping to port it to Delphi, but that would be clunky as Delphi didn't have reflection or,
as it turns out, longevity. I LGPL'd it, privately2, at that point.
I was working at Company A at the time, and we were in the middle of redeveloping all
of the internal applications into Visual BASIC, rather than the fudged, command line code currently in use. Soon after we were fully committed to developing in Visual BASIC Java arrived. We started playing around in Java. Eventually we started to redevelop the VB code into Java, but by that time I had moved to Company B.
History
All of my personally developed java code at Company A and Company B used DAOMedge.
From 2004 I was a DBA at Company B. In late 2004 I was tasked with the improvement of the data entry system, that was being done by a third party. I, naturally, started using DAOMedge officially. It was now that I submitted it to Source Forge making it LGPL for real which allowed me to use it for Company B and any other thing I needed it for.
Company B used MSSQL and Ingres as their databases, for reason's that are irrelevant to this page, so I could test against MSSQL, MySQL and Ingres.
I tried to shoehorn the various catalog/schema combinations into a consistent naming of value objects. This was unpleasant, but not an issue unless you were moving database rows from one type of database to another.
DAOMedge grew up during the next 18 years as more and more features were added and more and more select methods were added. By the time I had reached version 9 it was obvious that it needed a rewrite. So much had been added to Java in that time, the important one was annotations. When my employment at Company B came to an end, I was made redundant in 2021, I left them with version 9.2.6 and was determined to start from scratch using annotations and JavaFX.
JavaFX was being recalcitrant, in as much as I couldn't get a table cell renderer and editor to behave well when it came to tool tip texts. So in late 2022 I decided to ignore JavaFX and stick with Swing. I still thought annotations were the way to go though.
Version 10 is a complete rewrite, it targets Java 17, which is the latest (As of Feb. 2023) Long Term Support version of the JDK.
There is not a lot of sites using Java 17 so I have a bit of a buffer for bugs etc. and I have used Java 16 syntax (mainly text block).
The new version occupies a completely different namespace.
Instead of mapping XML files it uses annotations. Starting from scratch allowed me to rationalise the way in which SQL is built by the library.
It is much smaller and doesn't use third party libraries at all (except, of course, JDBC drivers).
Java 21 is also a LTS release, but it is early days as yet (as of Nov. 2023) so I'm sticking with 17 for the time being.
Command Line Interface
I have added a command line interface that you can use to generate directly.
Say you have two generators configured; my_database that doesn't have a stored password, and my_development_database which does.
java -Xmx2g -jar daomedgegen.jar my_database:password my_development_database
This will generate for my_database using the supplied password and then do my_development_database which has the password stored in the xml configuration file.
java -Xmx2g -jar daomedgegen.jar my_database my_development_database
This will prompt for a password and generate for my_database and then do my_development_database which has the password stored in the xml configuration file.
JDBC Drivers and Connection Strings
Light research on the web finds:
Database | Driver jar | Driver Name | Minimum JDBC Connection String |
MariaDB | mariadb-java-client.jar | org.mariadb.jdbc.Driver | jdbc:mariadb://server:port/database |
MySQL | mysql-connector-java.jar | com.mysql.jdbc.Driver | jdbc:mysql://server:port/database |
SQLServer Microsoft | mssql-jdbc.jre11.jar | com.microsoft.sqlserver.jdbc.SQLServerDriver | jdbc:sqlserver://server:port |
SQLServer JTDS* | jtds.jar | net.sourceforge.jtds.jdbc.Driver | jdbc:jtds:sqlserver://server/database |
Oracle Thin | ojdbc11.jar | oracle.jdbc.driver.OracleDriver | jdbc:oracle:thin:user/password@server:port:database |
Oracle OCI | ojdbc11.jar | oracle.jdbc.OracleDriver | jdbc:oracle:oci:@server:port:database |
DB2 | db2jcc4.jar | com.ibm.db2.jcc.DB2Driver | jdbc:db2://server:port/database |
*JTDS has been at version 1.3.1 for over ten years. It does work very well so I suppose there is no reason to change it at all. It doesn't handle instances very well though.
Object Browser
I have added a browser tool. This allows you to browser your database to see how the relationships work etc. It just uses the normal class path functionality (IE
not the URLClassLoader)
To use the browser, put all of the required jars into the class path and create an XML file for each connection.
Example XML file (called, say, my_server.xml):
<server>
<driver>some.package.jdbc.Driver</driver>
<url>jdbc:sql://server:port</url>
<username>username</username>
<password>password</password>
<maxrows>25</maxrows>
</server>
Example bash script:
Into a folder add the following jars:
daoobjectbrowser.jar, daomedge.jar, jdbc_driver.jar, your_coded_types.jar, dao_generated.jar.
You can use this bash script (assuming the jars are in the lib folder):
#!/bin/bash
cd /home/username/daobrowser/
jars=""
for f in *.jar
do
jars="${jars}${f}:"
done;
for f in lib/*.jar
do
jars="${jars}${f}:"
done;
echo $jars
java -cp "$jars" au.id.medge.daobrowser.DAOBrowser my_server
The my_server in the command line corresponds to the my_server.xml file.
If you are using coded types, then make sure the latest coded types are in the browser's class path along with the latest generated jar. If the coded types are
out of date or missing one the browser will throw an NPE in the console not in the log file. I've changed the browser for 10.0.10 to dispay the issue on the browser frame.
Future
I'll keep adding stuff to the library as it occurs to me or anyone using this library.
e.g.: I, momentarily, though about adding temporary relationships (ie building a daorelationship object on the fly) but getting right wasn't easy and it would fail often. As relationships in the DAO do not affect the database at all, it is simpler to use the generator.
PS: Feel free to do whatever you want with the earlier version. If you see missing functionality in version 10 from version 9 or if you have an idea
send it to me through the Source Forge feedback pages.
Observations
I added a table to my database the other day. It was the first one that uses nvarchar() on a MariaDB database. The generator detected it was a varchar, not nvarchar which would mean that values would be encoded as normal strings. I.E. 'test string' and not N'test string'.
I wondered if that would be an issue and I needed to detect the collation type of the column.
As it turns out, I do not. MariaDB reports it as a varchar, treats it as such and, with the collation, allows for unicode strings.
Is it that nvarchar and nchar are being deprecated? I can't find anything that suggests that it is.
Line and Class Count Bash Script
Shown here so I don't accidentally delete it or in other ways loose it.
#!/bin/bash
lineCount() {
cd $1;
declare -i fc=0;
declare -i tnblc=0;
declare -i tlc=0;
declare -i lc=0;
for f in $( find * | grep -E "\.java$" | grep -v datastructures )
do
lc=`wc -l $f | awk '{ print $1 }'`;
nblc=`grep -c '^[^*]' $f`;
tlc=$tlc+lc;
tnblc=$tnblc+nblc;
fc=$fc+1;
done;
echo "$1 has $fc classes; containing $tlc lines of which $tnblc are not blank";
cd ..
}
if [ "$1" == "all" ]
then
for param in `ls -d */`
do
lineCount $param
done
else
for param in $@
do
lineCount $param
done
fi
As of Sat 11 Jan 2025 15:09:34 ACDT
daomedge has 62 classes; containing 11498 lines of which 10781 are not blank
daomedgegen has 145 classes; containing 20537 lines of which 18379 are not blank
daoobjectbrowser has 23 classes; containing 2189 lines of which 1913 are not blank
Footnotes
Viewed
times.