I'm currently developing a java application where users shall be able to create profiles, sign in with their login data, store some information connected to their user profile, etc. within a database. As the application should come lightweight and the normal user who isn't as technophile as developers might not want to manually set up a database on his system prior to being able to use the application or even might not be able to do so.
Hence what I am going for obviously will be an embedded database. As I've already read through several posts dealing with embedded databases and how to access them I'm already aware that I won't be able to simply pack an initialized - yet empty - database within my .jar file and let users store new data in it as it will be static and read-only when packed within the .jar file.
But as obviously there has to be some way to set a database up without even bothering the user with its creation or configuration I'm now asking myself What are the usual ways to do so? How is this typically done? Because obviously there are a lot of applications that use non-static embedded databases.
An idea I've come up with is creating such an empty, initialized database which then will be packed within the .jar file and upon each launch of the application, the application looks for a appropriate database file within its current location and if it doesn't find one it simply copies the empty database packed in its .jar file to the folder. But I'm not sure if this would actually be enough to make this work or if this is actually properly achievable or if there's no better way to do so.
I'm really curious for what a typical solution of this scenario looks like and thanks in advance for your input and ideas on this.
Related
I am currently developing a program in Java using NetBeans that manages expenses. In this program I used MySQL to store data. Now I want to ask that if I give the program to one of my friend, he would also have to install MySQL using the same password that I used. Is there a way in which he will not be required to install MySQL?
Now suppose if my friend already has MySQL, but with a different password. My program would not work in that case, and it would be hard to replace my password with his password in the code. Is there a way to make the program run on his PC?
Earlier once, I have used an Oxford dictionary program. That time I did not have Microsoft Access installed. When I installed Microsoft Access I came to know that all the words of the dictionary are stored in a Microsoft Access file. How can I do this? I.e. how can I use MySQL/Microsoft Access to store data without the need to install either of them?
You can use an in-memory database like H2 Database if you don't require a large amount of data
But I think you should make your db connection configurable by using a properties file
If you want everyone to be able to use the database, you need to run it on a server that people can access through the internet.
However if you don't care about them using the same database and just want them to use their own, you could for example create a small file named "config.ini" or something like that and put the login information (like the password) in there.
Then just read it in your code and use the info you read to log into your database.
That way, every new user will only have to change the config.ini file without ever having to touch the code.
The best solution in my opinion would be SQLite as it is light, and data can be stored locally in a desired location in a single file. H2 is more likely to be a developer tool.
This solution does not require additional software to be present on the user machine. Of course it has its limits, but as a simply storage for program dynamic data it is a good solution. It is worth mentioning that Android applications also can store their data in LiteSQL. It is a bit different approach there, but the principle stays the same.
I have a Mac Java application that needs to persist data across reboots. The data needs to be saved so that any user has access to it. E.g. an SQLite database file that can be used for all users.
It looks like the /Library/Application Support/ folder is supposed to be used for this, but I'm not able to write to it without making my app run as root or changing the permissions of the file to rwxrwxrwx.
What is the proper way to save application-level data on Mac?
The developer documentation covering this is a bit of a large topic:
https://developer.apple.com/library/Mac/referencelibrary/GettingStarted/GS_DataManagement_MacOSX/_index.html#//apple_ref/doc/uid/TP40009046
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010672
According to the File System Programming guide you should make a specific subdirectory inside /Library/Application\ Support for your app to store app data common to all users on the system. I'd use reverse domain name notation such as com.yourcompany.yourapp or something else unlikely to collide with another app's use of the common directory for this.
You might also look into using an existing app bundler for OS X such as https://bitbucket.org/infinitekind/appbundler rather than hard code paths to file locations.
I have a requirement in my project to keep some configuration properties in a .properties file (server_config.properties) so that it can be altered without hard coding key-value pairs e.g server_url = http://www.mydomain.com
server_port : 5000 ....etc and there can be 100's of properties in this file.
I am thinking why not keep the key-value pair configuration in database table and read it from there.
Can you guys please share your experiences of using both approaches and mention what are the advantages and disadvantages of both?
In my opinion , I think keeping in a database table should be better approach, in that way I can change the values in database and they can be loaded dynamically into server via JMX calls , and could be shared by multiple instances of my application.
Please share.
I think it depends: are these configuration values which you might want the user of the system to be able to change? Then, YES, database (and you can add a web page to create/retrieve/update/delete later). However, if these are more "hidden" configuration values for the system manager (you), then I would not see any good reason to have them in the database.For example, you can't specify parameters related to the database which are stored in the database.
Sure, the configuration file might get large, but 100's of lines is not really that big, and you can split it into multiple configuration files if you'd like (server_config.properties, database_config.properties, user_config.properties, etc) and easily add comments.
However, on the database "pro's", I would add that you can track who modified a parameter (if your webpage has user login information).
When you write "server_config.properties", then that sounds like Java and a new Properties().
I've created a Java application that is basically an interface to a MySQL database. It helps organize and keep track of data. We are using it in my workplace with no problem - I have exported it from Eclipse as a jar file and given everyone a copy of this jar file.
Now we want to make this software available to other workplaces. The problem is that the URL, username, and password for the database are hardcoded in the application. I want to create a setup process for it so that when someone downloads it, they go through a wizard that downloads MySQL and sets up the database wherever they choose. The person can then distribute the jar file to everyone in their workplace without them having to do the setup, because everyone will be accessing the same database.
This process must save the database URL, username, and password somehow so that the people in the workplace can run the jar from whatever computer. This makes me think that they should be saved inside the jar... is a Properties file that I need? Can I put a Properties file inside the jar and allow it to be edited during the setup process?
Any guidance is greatly appreciated, I'm very new to this!
==================================================================================
EDIT: I think what I'm going to do now is let the user install MySQL and set up their database themself. As the answers below suggested, having this automatic might be more trouble than it's worth, as I would have to deal with everyone's different platforms, preferences for setting up the database, security concerns, etc. Once they do this, they will just download my jar file.
I've added a properties file to my jar file to store the database URL, username, and password. This file is initially empty, so when the user runs the jar for the first time, the program will attempt to access the properties file, see that it's empty, and prompt the user to enter this information. It will then extract the properties file from the jar, edit in their information, and stick the properties file back into the jar. Then, the person should be able to distribute the updated jar to their coworkers and they should all be able to open it without having to supply that information. I've got this part almost working. I'm also going to add the ability to "reconfigure" the program - in case the user moves their database - by calling the same method (they would again have to distribute the new version of the program).
Next I want to try securing the properties file somehow by encrypting it or obfuscating the code (although I think that only works for class files and not text files...?). My concern is that anyone in the workplace can unjar it and open the properties file, then use the URL, username, and password to access the database on their own and cause damage. Ideally, no one would be able to unjar it at all except for the program itself.
If anyone has other concerns about my method, please let me know!
First, it would not be trivial to set up a database in a central location in a workplace so that it is accessible by different users. Also, there is the problem of the first user setting it up and then re-distributing the application to others.
Answering the technical questions - the easiest way would be to unjar to a known location, edit the properties file at that location, and then re-jar to a new file, perhaps with a suffix specific to that workplace.
You could save the property file in a subdirectory of the user home directory, obtained by System.getProperty("user.home). Also, have a look at the Apache Commons Configuration library.
How do you deploy your Application?
If you're using Webstart, you could define your properties in your jnlp-File and access them with System.getProperties(...);
Take a look at HSQLDB. It is a lighter weight db that is rely easy to setup. You can configure it to me the db if it doesn't exist and us it if it does. However, if you need something like MySQL and want to have many users connecting to it from different workstations, I would not recommend downloading and configuring it through an install process. There will be a lot of network and security concerns. As a side note a properties file is a good idea.
This is a link that explains some of the security concerns to think about. Also, thinking about this a little more, users might not have the necessary permissions to setup/configure a db server. It is probably safer/easier for you in the long run to allow them to set up the db server and have them put a properties file in your applications classpath.
As a side note, have you considered making this a web application? That could make things even simpler for you, people wouldnt have to download anything, and there would be no setup for most users.
I am creating a Spring MVC Hibernate application using MySQL. Where should I save the User Images: in the database or in some folder, like under WEB-INF/ ?
Certainly not inside WEB-INF. You might want to save them in the file system, but not in the webapp's directory. First of all, it could very well be inexistent, if the app is packaged as a war. And second, you would lose evrything as soon as you redeploy the app. Desktop apps don't store their user data in their install directory, do they? It should be the same for webapps.
Now, since images are usually big, and they're not searchable, you might want to store them on the file system, and only store their name, path, hash, and/or mime type into the database. But it depends on your application, if they need to be served/used by other applications, if these apps have access to the database and/or the file system, etc. You decide.
You can choose it:
DataBase - you have the positive point that this can be associated with records and will never be orphan (depending on your model). For backup it is a little bit painful for situations in which the database increases.
FileSystem - backup facility, as these are physical files, an rsynch process should be enough. Another positive point is that you reduce the IO from DB. Although, it is quite hard to attach a logic between the files and the record stored in the DB (you have things distributed), so you will not be sure if the file wasn't removed and there are still some records referring to it in DB.
If filesystem option is chosen, put it outside the application directory structure (prepare a dedicated place for the files). The application dir should not be modified, causing some pain when redeployment is done. You can use symbolic links though.
With images, probably you want to perform some thumbnails and so on, this would be cheaper using FileSystem option.
That depends what you're trying to accomplish.
If these are static images , and you have a fixed number of users ,you can consider saving them under WEB-INF/.
However, most likely this is not you case, and you have varying number amount of users and you have to store a user for each one of them.
Possible solutions:
A. For the user store an image name, and have a convention of storing/loading from a well known directory in your file system.
B. Store the image as a blob in your DB. Consider checking the #Lob annotation