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
Related
I need to clear all app data including cache without killing the application. All solutions I have seen either just remove cache data or they kill the application after removing app data. Is there any way to do aforementioned thing without the application being closed?
Android developers save user data mainly in three locations. File System DataBase SharedPreference.
File System
context.getCacheDir();
context.getFilesDir();
context.getExternalCacheDir();
context.getExternalFilesDir();
You can navigate the file system and delete the file you create.
Database
You can use context.deleteDatabase(String name); to delete the database you create.
SharedPreference
context.getSharedPreferences(String name, int mode).edit().clear(); will remove all values in the sharedpreference file.
Indeed, it's your responsibility to find all the files and directories your app creates. I think it's hard to do it exactly right.
And with the application running, it generates new files when you are cleaning the room. So the methods above can provide your user a way to minimize storage usage, but can not really completely remove all data.
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.
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'm building a dictionary application and I have a problem right now. My application's is 16MB and when I install it on a phone, Database files copies to the data folder and in the manage apps section I see that my application size is 32MB (my app+data folder).
I don't cheat user, I want to say, my app is 16MB, but when user install it , it become 32MB. Why? this is a negative point and I want to solve it. I want my app uses only 16MB in users phone. just that
How I can fix this? I have to read and write in assets folder directly or there is other solution? this is a problem in low storage size phones. how I can fix this?
I am not sure how your database is structured in terms of whether it is a pre-loaded database wherein you just include you .db file with all the data OR is it something where in you push all your DB content with the app and then at the time of app installation you actually install all you data in the DB.
In case of the latter situation you double the size of your app because you already have data content (in files) which you want to use to populate your database (say 16 mb in this case). Then you use these files to actually create your DB file (which is 16mb again) and this doubles the size of the app.
So what you could do is pre-populate your DB content in a .db file and then just use this file directly as the Db file in your app (this will keep it to 16mb). Follow this tutorial :
http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/
Hope this helps.
Not sure I fully understand your situation.
Do you have a roughly 16MB dictionary, that is packaged inside your app as string constants in your code or some resource file or something (to make it 16MB) and then, when your app installs or first launches, you also write this dictionary into your app's database?
If so, then now you have 2 copies of your dictionary around to make it 32MB.
To solve this, either keep only one copy in your app, or download the dictionary from somewhere to get it into your database rather than storing it as a constant in your app.
I am working on rewriting a Java web application to Rails which relies heavily on collections (100's or 1000's) of large (50-100MB) TIFF files. In the Java version, the user specifies a local root path (such as a mounted SAN drive) for these files in the application configuration, and they are read by the application using these paths. The application also writes new files to those paths.
Essentially, users must be able to add files to the application in two ways:
1) Specify a storage location as the 'root' for a collection of TIFFs, which could already contain many TIFFs. These are then processed.
2) Upload new files to an existing collection, which would then be written to the above path and processed.
I guess the gist of my question is: What is the standard way to store, retrieve, and write to such large files in the context of web applications? Should the availability of a local file system with enough storage space be assumed, or is there a better way to do it?
I would look into storing the files with paperclip or carrierwave. They are two great file upload and management gems that allow you to store your files in many different ways.
I have included links to two great sceencasts above and here are the github pages for paperclip and carrierwave.