suppose that I have an Employee Class and there is another Class Company that has more than one Employee so I want to save the Employee objects locally, that means every time I run my application I can retrieve these objects.
I would suggest using some kind of embedded solution. There are a number of options available such as H2 or Neo4j.
For a comprehensive list check out Wikipedia.
Although these solutions are technically databases the don't run on their own server, they run inside your current Java process.
To get started with H2 the following steps are required:
Add the h2*.jar to the classpath (H2 does not have any dependencies)
Use the JDBC driver class: org.h2.Driver
The database URL jdbc:h2:~/test opens the database test in your user home directory
A new database is automatically created
After that, you can simply use JDBC against the new database everything is stored on disk.
I would not recommend using Java-serialization of Java objects to a file (Serializable). This is not a maintanable solution and whenever your code changes (for the classes that were serialized) you have to work out some plan on how to migrate your data.
Another solution is to dump your object graph as JSON in a file. There are multiple libraries that can help you with serialization and deserialization from Java to JSON and vice versa. One example is the excellent Jackson library that easily and without fuzz converts objects to and from JSON.
you can use Microsoft Excel to save the attributes of this object and retrieve them later, there is an api for excel http://poi.apache.org/download.html
Related
I want to create an impex from java in hybris, because my requirement is to add the featureproperty dynamically , instead of doing it from HMC.
I have never done impex from code and I have seen no example on the internet for reference,
If impex cannot be done from java then what is the best bet for me to make it dynamic.
I am new to hybris. Any reference or hint will do for me. Please help,
Thank you
Impex is used for importing and exporting data. You have multiple options to import data using Impex files.
Manual import during Initialization/Update process
The Initialization/Update process is used to create all data, that is needed for starting the platform. During this process hybris creates tables/columns in the database, the type system and it also imports data. This data is classified as "Essential Data" that is essential for the system to start (like currencies, languages, users), and project data, which is necessary for a specific extension to run. When you want to use the accelerator, all the data, that is needed is created in the myacceleratorinitialdata extension. With this extension you can create a basic web shop (like web sites, stores, catalogs) and even sample data (like sample products/prices/stock, sample cms pages/components, sample media items).
Using hot folder
The hot folder is often used for automatic/periodic import of data. On the servers hard drive there is a folder which is monitored for changes. When a CSV file is put to this folder, the data in this folder is imported into the database. However you have to configure how it is imported. It is often used to import updates for product, price or stock data.
Manual import by uploading file in the hybris admin console
In the hybris admin console there is a page where you can import a snippet of impex content. It is often used to do mainenance work (like manually disabling a number of products). The default URL pointing to that service is:
https://localhost:9002/console/impex/import
Impex API
If you REALLY need to import Impex data via Java code, there is an API:
https://help.hybris.com/6.5.0/hcd/8bee24e986691014b97bcd2c7e6ff732.html
In my many years of writing hybris applications, I never had to use this API. Often it is more suitable to use one of the above mentioned mechanisms OR the ModelService (see below).
Keep in mind, that every data item you want to create, can be created using the ModelService. It's very simple to write data to the database using the ModelService. Here is an simplified example for how to create a new product using the ModelService:
ProductModel product = modelService.create(ProductModel.class);
product.setCode("123");
product.setDescription("A product imported using ModelService");
product.setCatalogVersion(catalogVersion);
modelService.save(product);
For every data type, there is a Java class with the suffix "Model" (e.g. ProductModel, StockLevelModel, PriceRowModel, MediaModel). These model classes have getter and setter methods for every attribute of that data type (e.g. product.setCode(...)). Even relations to other data types can be retrieved/saved using getter/setter methods (e.g. product.setCatalogVersion(...)).
We can create impex using Java springs. You can check hot folder implementation where impex is generated through the OOTB java classes.
you can check in yaccelerator core integration spring files for better understanding.
I've got an existing Grails/MongoDB application that I am adding some automated tests to. I want those tests to be executed against a specific set of data in a Mongo collection. I want the tests to be able to mangle the data (with predictable results, if I'm lucky) and then be able to quickly drop and recreate/reload the database so that I can run the test again.
Since I'm going to base this seed test data on real data from our production system, I'd like to be able to perhaps load the data from a JSON/BSON format that I could retrieve from a query in the Mongo shell or something similar.
Basically I don't want to have to write a hundred lines of code like the following:
new Record(name: 'John Doe', age: '25', favoriteColor: 'blue').save()
Except with 30 properties each, all the while ensuring that constraints are met and that the data is realistic. That's why I want to use production data.
I also don't want to have to resort to spawning execs that run mongorestore to load and reload real data, since that would require additional software to be running on the tester's machine.
Is there a better way? Perhaps somehow unmarshalling raw JSON into something that I can then execute with the Grails MongoDB GORM or GMongo or a direct call to the Java MongoDB driver?
Do you need to store your test data in a transportable file, or will you always have access to a mongodb instance on which it could live? Say, for example, that you have a test mongodb server and that you can rely on having access to it whenever your tests are run.
In that case, the simplest solution is to keep the test data in a collection which you'd clone before each test run. Tests would then be free to mangle the cloned collection as much as they want without any actual data loss.
If you need to have your test data live in a file (because, for example, you want to store it on your code repository), then you need to find a format that's easy to serialize to / deserialize from BSON. JSON seems like an obvious choice, especially since, as #drorb said above, mongodb has tools to do that for you already.
You'd then just need to write one script to dump the content of an existing collection in JSON files, and another to load a set of JSON files and store them in a collection - probably not more than a few lines each.
I'd suggest storing each object in a separate JSON file rather than have a large file with all the test data. As much as I like JSON, it doesn't lend itself well to streaming, and you'd have to store the whole collection in memory before you can start dumping it in mongodb. If your test data is big enough, it could start causing memory problems.
You can use the com.mongodb.util.JSON class to convert JSON data directly to a DBObject.
Take a look at this example which demonstrates how to do it using the Java driver.
This MongoDB blog post shows how to do it using GORM and the Groovy driver.
I am making a math game in Java and I want to create the ability for the user to create a local account (or log in to an existing one), which would have a unique properties file. How would I do this?
You have a couple of options to look into. Java comes with the necessary libraries with which you can create, open, read and write to files. Using the File class, you could create an account file, for instance "User1.properties", and save the information in an easy to parse format. If you're looking to go one further, you can look into using XML or JSON, which are commonly used formats for saving information in this way. Here's some helpful links to get you started.
Using files in Java
Using XML in Java
Using JSON in Java
Another option you have available is to use a database in a similar fashion to websites. The type of database you use is up to you, although MySQL is an example of one commonly used database. Once again, here is a link to help you get started with MySQL in Java.
Regardless of what you use, you will need to take the username and password provided (or whatever combination of login credentials you would like your system to use), and compare them with those stored in your file or database.
I'd like to save persistent objects to the file system using Hibernate without the need for a SQL database.
Is this possible?
Hibernate works on top of JDBC, so all you need is a JDBC driver and a matching Hibernate dialect.
However, JDBC is basically an abstraction of SQL, so whatever you use is going to look, walk and quack like an SQL database - you might as well use one and spare yourself a lot of headaches. Besides, any such solution is going to be comparable in size and complexity to lighweight Java DBs like Derby.
Of course if you don't insist absolutely on using Hibernate, there are many other options.
It appears that it might technically be possible if you use a JDBC plaintext driver; however I haven't seen any opensource ones which provide write access; the one I found on sourceforge is read-only.
You already have an entity model, I suppose you do not want to lose this nor the relationships contained within it. An entity model is directed to be translated to a relational database.
Hibernate and any other JPA provider (EclipseLink) translate this entity model to SQL. They use a JDBC driver to provide a connection to an SQL database. This, you need to keep as well.
The correct question to ask is: does anybody know an embedded Java SQL database, one that you can start from within Java? There are plenty of those, mentioned in this topic:
HyperSQL: stores the result in an SQL clear-text file, readily imported into any other database
H2: uses binary files, low JAR file size
Derby: uses binary files
Ashpool: stores data in an XML-structured file
I have used HyperSQL on one project for small data, and Apache Derby for a project with huge databases (2Gb and more). Apache Derby performs better on these huge databases.
I don't know exactaly your need, but maybe it's one of below:
1 - If your need is just run away from SQL, you can use a NoSQL database.
Hibernate suports it through Hibernate OGM ( http://www.hibernate.org/subprojects/ogm ).
There are some DBs like Cassandra, MongoDB, CouchDB, Hadoop... You have some suggestions Here
.
2 - Now, if you want not to use a database server (with a service process running always), you can use Apache Derby. It's a DB just like any other SQL, but no need of a server. It uses a singular file to keep data. You can easily transport all database with your program.
Take a look: http://db.apache.org/derby/
3 - If you really want some text plain file, you can do like Michael Borgwardt said. But I don't know if Hibernate would be a good idea in this case.
Both H2 and HyperSQL support embedded mode (running inside your JVM instead of in a separate server) and saving to local file(s); these are still SQL databases, but with Hibernate there's not many other options.
Well, since the question is still opened and the OP said he's opened to new approaches/suggestions, here's mine (a little late but ok).
Do you know Prevayler? It's a Java Prevalence implementation which keep all of your business objects in RAM and mantain Snapshots/Changelogs in the File System, this way it's extremely fast and reliable, since if there's any crash, it'll restore it's last state and reapply every change to it.
Also, it's really easy to setup and run in your app.
Ofcourse this is possible, You can simply use file io features of Java, following steps are required:-
Create a File Object
2.Create an object of FileInputStream (though there are ways which use other Classes)
Wrap this object in a Buffer object or simply inside a java.util.Scanner.
use specific write functions of the object created in previous step.
Note that your object must implement Serializable interface. See following link,
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.