I'm trying to make an executable .jar file from a program that uses both an SQLite database and a serialized read/write file system for storage inside the program. We are able to make an executable .jar file, but it doesn't read from any database nor file system that we have written within the program. Does anybody know how to do this?
"To make a .jar file read from a database" when you have a Java or Kotlin (or Scala) program which does that you are almost done, you just have to compile it and which provides you a .jar file which does exactly that.
I think your question is what does it take to write a program that does it.
For that you have to think about what your database should be able to handle.
Read from filesystem
A text file on a disc is very rudimentary but might suffice if the application is just to read/write some persisted state. For that the Java API has all you need, take a look at Baeldung - read from file via NIO.
Read from database
If you need transactions or support for multiple applications working with the persisted storage, a database would be the more sensible thing to use.
Although the Java API again provides you everything you need for that (e.g.Processing SQL Statements with JDBC) you would need to reinvent the wheel in a sense. The easier thing would be to rely on an OR-mapper like Hibernate or JOOQ.
For writing enterprise Java software you could overengineer it with Spring-Boot JPA.
Related
I have a method that creates PDFs and a servlet that uploads files to my database. Is there anyway I could directly upload the created PDFs to my database? I am using FileOutputStream to create my PDFs.
Sounds like you need something like Java Caching System or Ehcache. Putting PDF's in a database is generally not a good idea, though it has certainly been done.
I suppose it depends on how long you expect the user to want to retrieve the file. If a long time, perhaps a database could have advantages because it is administered, backed up, etc. However, all the same things can be said about a file cache and if you have a lot of the files then you should have much happier system admins using a simple file store.
I'm using Apache POI API to access an Excel .xlsx file, using the API I can read/write cells.
My problem is: How can I do that with the .xlsx file opened in Excel GUI?
If I try to do that I have conflict arising from concurrent access to the same resource (The process cannot access the file because it is being used by another process).
I have been told that the answer is Excel RTD and c#, c++ or other languages.
BUT I want to stick with Java,what could I do? Is switching to linux an option?
THANKS!!!
AFAIK poi only works on the file system, so there is no interaction through Real-Time Data. I think you should not edit the xlsx file while it is still open in excel if you want to prevent corruption.
If you want to use RTD, you should try to find java bindings for that. I think they are COM based, so maybe JACOB can help you. http://sourceforge.net/projects/jacob-project/
See also this discussion: http://sourceforge.net/p/jacob-project/discussion/375946/thread/946012e8/
Oh. Btw. COM is Windows only, so I would stay on Windows :)
Accessing and modifying a resources by 2 separate entities at the same time does not imply that you'll end up with a synchronized version at both ends. On the contrary, provided you manage to do so you have all the chances of ending up with an incorrect/bogus/corrupted result. Translated into java, you may think of it as multiple threads altering a variable in an unsynchronized way.
Some programs (notepad++, idea, eclipse on editor reactivation, etc) have implemented additional mechanisms which will detect if a file has been modified on the file-system outside the program itself, and provide you with options such as: reload file, ignore modifications, merge, etc, and others simply ignore these changes overwriting the file.
My guess is you'd have to do a similar thing or rethink your scenario about updating the files and triggering notifications.
As the other users said, there is no way to do this from poi. Options:
Your best option is RTD (you write a thin RTD "server" in C#, install it in the registry, and talk to it from java, e.g. via some socket; within excel, users just enter RTD formulas in their cells, for which excel calls your rtd server to get the latest data).
You can also write the data directly to excel using COM (there are also java libraries to do this, such as teamdev's jexcel, or you could write your own com wrappers).
You can write your own excel plugin.
Finally, there are lower level solutions which I've heard talk of but don't understand.
I'm looking tools/libraries which allows fast (easy) data import to existing database tables. For example phpmyadmin allows data import from .csv, .xml etc. In Hadoop hue via Beesvax for Hive we can create table from file. I'm looking tools which I can use with postgresql or libraries which allows doing such things fast and easily - I'm looking for way to avoid coding it manualy from reading file to inserting to db via jdbc.
You can do all that with standard tools in PostgreSQL, without additional libraries.
For .csv files you can use the built in COPY command. COPY is fast and simple. The source file has to lie on the same machine as the database for that. If not, you can use the very similar \copy meta-command of psql.
For .xml files (or any format really) you can use the built in pg_read_file() inside a plpgsql function. However, I quote:
Only files within the database cluster directory and the log_directory
can be accessed.
So you have to put your source file there or create a symbolic link to your actual file/directory. Then you can parse it with unnest() and xpath() and friends. You need at least PostgreSQL 8.4 for that.
A kick start on parsing XML in this blog post by Scott Bailey.
I'm new to the SQLite database, and more generally, to the concept of embedded databases altogether. I'm used to creating a connection string and connecting to a remote DB server (MySQL, MSSQL Srv, Oracle, etc.). I know this question is probably quite silly, but being in uncharted waters here, I can't seem to find the answer to this on my own.
So I'm writing a Java app that uses SQLiteJDBC as the Java driver for SQLite (the app's embedded db) and am creating the tables and inserting records into them from the Java app itself. What I'd like to do is download/install SQLite on my system - completely independent of the Java app - and then write SQL scripts that will do the "skeletonizing" (creating & insertions) of the database file itself, then copy that .sqlite file into my project directory where the app can then use it.
I'm just finding it incredibly difficult to develop database schema from inside the Java app itself; just seems like an unnecessary step.
So, my question:
Is this even possible? To create, say, myProgramDB.sqlite off the command line with the SQLite tool, and then (essentially) cut-n'-paste that file into my Eclipse/NetBeans project (of course, in the right directory!) and have it work? This is also assuming I have correctly imported the SQLiteJDBC JAR into my project through the IDE. I just want to create the DB somewhere else, then copy it into my project, instead of developing the DB through my app directly.
Thanks for any insight!
Just think of the database as a normal file which your app refers to either by an absolute or relative file path, so with that in mind embed it in your project like you would any other file in Eclipse (or point to a specific location where you expect it to be).
If you're going to create your db manually, SQLiteStudio (http://sqlitestudio.one.pl/) is free tool which will help you build the schema.
It also lets you export the structure and/or data as sql statements, which you can then use to build a copy of your database elsewhere.
Is this even possible? To create, say, myProgramDB.sqlite off the
command line with the SQLite tool, and then (essentially) cut-n'-paste
that file into my Eclipse/NetBeans project (of course, in the right
directory!) and have it work?
Yes of course, you can do it. Haven't you got somewhere in your code a getConnection method call? It's used to connect to the desired database. In your case should be something like:
DriverManager.getConnection("jdbc:sqlite:" + databaseName);
I just want to create the DB somewhere else, then copy it into my
project, instead of developing the DB through my app directly.
That's reasonable. The only thing that you might consider is this: if your application depends on the database "skeleton" as you said, then a database file (talking about SQLite) must always be available in order to proper run your program. Embedding inside your application, the basic instructions to create the database tables required, could permit to the application to rebuild a minimal database if the file is accidentally lost.
There are a number of GUI schema-creation and browsing clients for SQLite.
CAVEAT:
There are some differences in the way various implementations of SQLite differentiate (or don't differentiate) between INTEGER datatype and the other ways of expressing integer, such as INT, INT32, BIGINT, etc., especially when then column is a primary key.
If creating a SQLite schema outside of the implementation where you plan to use it, use "INTEGER" (verbatim) when assigning integer data type affinity to a column; do not use any of the other variants of int.
My Java application is currently using ZIP as a project file format. The project files contain a few XML files and many image and sound files.
The project files are getting pretty big, and since I can't find a way with the java.util.zip classes to write to a ZIP file without recreating it, my file saves are becoming very slow. So for example, if I just want to update one XML file, I need to rewrite the entire ZIP.
Is there some other Java ZIP library that will allow me to do random writes to a ZIP file?
I know switching to something like SQLite solves the random write issue. Would using SQLite just to write XML, Sound and Images as blobs be an appropriate use?
I suppose I could come up with my own file format and use RandomAccessFile but then there would be a lot of bookkeeping I'd have to write.
Update...
My file format is very much like Office Open XML. It is a ZIP file containing XML and other resources.
Someone must have solved the problem of how to do random writes to update a ZIP file. Does anyone know how?
There exist so-called single-file virtual file systems, that let you create file-based containers and provide file-system like structure and APIs. One of the samples is SolFS (it has C-written core with JNI wrapper) and some other C- and Delphi-written solutions (I don't remember their names at the moment). I guess there exist similar native Java solutions as well.
First of all I would separate your app's resources in those that are static (such as images) and those that can be changed (the xml files you mentioned).
Since the static files won't be re-written, you can continue to store them in a zip file, which IMHO is a good approach to deploy any resources.
Now you have 2 options:
Since the non-static files are probably not too big (the xml files are likely to be smaller than images+sounds), you can stick with your current solution (zip file) and simply maintain 2 zip files, of which only one (the smaller one with the changeable files) can/will be re-written.
You could use a in-memory-database (such as hsqldb) to store the changeable files and only persist them (transferring from the database to a file on the drive) when your application shuts down or that operation is explicitly needed.
sqlite is not always fast (at least in my experience). I would suggest individually compressing the XML files -- you'll still get decent compression, and just use the file system to save them. You could experiment with btrfs, or just go with ext4. If you're not on Linux, then this should still work okay, but it might not be as fast until things are cached in memory.
the idea is that if you do not have redundancy between XML files, then you don't get that much saving by compressing them in one "solid" archive.
Before offering another answer along the lines of using properly structured JARs, I have to ask -- why does the project need to be encapsulated in one file? How do you distribute the program to users to run?
If you must keep a project contained within a single file and be able to replace resources efficiently, yes I would say SQLite is a good choice.
If you do choose to use SQLite, also consider converting some of the XML schemas to one or more SQL tables rather than storing large XML documents as BLOBs.