I am working a project that will require a custom "wizard" to help a non-technical user to install a custom database driven application. The main concern is to not set up a new database for the custom application if there is a suitable database engine already in place. So the question comes: how to programmatically detect the type and location of existing database engines?
The trick here is that the requirements for the installer are that the wizard assists a non technical user decide if a database engine exists on the local private network that is on the compatibility list. If so, assist the non technical user with forming a connection to the selected database engine. Otherwise the wizard is to install a database etc.
Would it be better to just install the preferred DBMS regardless of the existing database scene? The platform is a windows box, but platform independence is a goal of the project.
I don't know if I am just using the wrong search terms or if there is little to no real information to this effect, but finding out if this is even possible has been frustrating.
Any help, advice, links, code resources, etc. will be greatly appreciated.
EDIT The goal of detecting the location and type of existing databases is to provide a simple list that a user can select from, for the case of adding an additional instance of the application on a private network for the current version or as an upgrade of the version (to effect a "clean" install). The application is a bit distributed in that there are typically going to be many instances of the application (3 - 10) working as terminals to interact with the database, manipulating the information in different ways for different uses on different terminals. The I think the preferred DBMS has settled on PostgreSQL.
Steve
If you know what type of database you're trying to connect to, you should be able to ping the default port for that type of database to see whether it returns a response. Or alternatively, try to open an actual connection to the database and see whether you get a response.
Getting more complicated, if you can access the PC on the network, browse to the default installation directories for the database type to see if anything exists.
These 2 so far would require the database to be installed using default locations and ports.
Getting more complicated, if you can connect to the registry on the remove PC then you can probably locate the database in the registry tree - this is going to be fixed no matter where the user installs the database
My suggestion would probably be to completely avoid this though, as it adds a lot of complexity without much payback. If your application is for a non-technical end user, it'd probably be better to just assume that there isn't any databases available to them, and just install a new one as part of the installer. Non-technical users are only going to be confused if you present them with a whole list of database options that really don't mean anything to them.
It could also potentially take a long time to query your local network, depending on how many network shares exist, and how quick they are to respond. All this would take away from the responsiveness of the installer, so the end user might not know why the installer isn't doing anything.
If you really want to give the option of choosing an existing database, I'd make it a separate optional button which would take them to another screen where they can choose a network host to investigate - the only people who would get to this screen would be more technical people who would probably know where a database exists anyway.
The main concern is to not set up a new database for the custom application if there is a suitable database engine already in place.
I don't quite understand how a wizard can determine whether an existing database is suitable. Suppose it finds 3 Oracle and 4 MySQL instances on the network – how will it choose? Moreover, such an approach creates a dependency between the user's application and another machine on the network, without the user's even being aware of it. What will the user do when the database's unavailable tomorrow?
It seems to me that if the data needs to be shared among several users or several systems, then selection of the DB must be an explicit, conscious operation by the user. If, on the other hand, the database is just a place where the application stores some stuff, then it should install one – preferably a lightweight one like HSQLDB or SQLite.
Related
I'm still rather new to java and I think I've started a project with a problem.
I created a job for a friend in which there are employees, shifts, sites and these needed to be loaded at the beginning.
I went looking for solutions and decided to use a Derby database. I've now programmed the Application and it works fine with the database. It loads all parameters and creates objects for handling,
Now I need to deploy my project to my friends computer so he can use it and I think I have the database set up wrong. I think I needed it to be embedded? so it goes with the application.
So my questions are what are my choices,
I read I can change the database to an 'embedded' one by making the database a class? I have no idea how to do this and maybe because I'm new to java, I'm finding all the write ups on this subject difficult to understand.
Alternatively I thought maybe I can install Derby separately and connect to that?
Or maybe I can drop the Derby idea and switch entirely to another database entirely,
I'm a bit confused over my choices here, basically I've built an application around an installation of Derby DB using this line to connect to it.
jdbc:derby://localhost:1527/SG_database
If someone can give me some 'Plain English' options here I would very much appreciate it.
To reconfigure your application to use Derby as an embedded database, all you have to do is change that JDBC Connection URL to jdbc:derby:SG_database, and change your CLASSPATH so that your program references derby.jar rather than derbyclient.jar. You should possibly add ;create=true to the end of that URL so that, the first time your friend runs your application, the database is created on their machine.
But yes, you have other choices, and without knowing a fair amount about your application it's hard to give you very detailed guidance.
When your friend is using the application, do you want you and your friend to be sharing the same set of data? Or is your application designed so that your data and your friend's data have nothing in common?
If you want to be sharing the data, then yes it will be important to have a single instance of the database, and both of you have to share it, in which case a client-server configuration can work quite well.
If you want to be two completely separate applications, with nothing shared, and each of you has your own copy of the data, then an embedded configuration can work quite well.
Perhaps you could simply try the embedded configuration, see how it behaves with your application, and then return here if you have a more specific question to ask?
I couldn't find an answer to this question. How can I export a Java project that makes use of a PostgreSQL database?
I want to use the same database on another computer. Do I need to export the database itself with the project? How can this be done?
What should the connection URL be, so that the database is accessible on another computer?
I'm using JDBC, and I'm on Windows.
Thanks in advance.
EDIT: Wouldn't I also need to dynamically retrieve the username and password on the other computer, instead of using the specific username and password I have on my computer in PostgreSQL?
It really depends on what you want to achieve.
Shared database between hosts
Do you want the application on both computers to use the same database, so that changes made by one are seen on the other? If so, you need to configure each copy of the application to connect to the same database instance on one of the machines. This is usually done by changing the JDBC URL. You'll need to configure PostgreSQL on the machine that'll be the database server so it allows connections from the other hosts, ensure they can talk to each other over TCP/IP, etc.
Fresh DB on each host
Do you want each install to have a separate instance of the database, so changes made on one have no effect on the other, and where each instance starts out with a blank, empty database (or one with only static contents like lookup tables)? If so, you should generally define the database using SQL scripts, then have the application run the SQL scripts when first installed on a machine. If you've defined the database by hand so far, you can use pg_dump to create a SQL script that you can use as the basis for this, but I really advise you to look into tools like Liquibase for schema management instead.
"Fork" current state
Do you want each instance of the application on a machine to have an independent database, so changes made on one have no effect on other instances on other machines, but where the starting state of an install is what was in the database on the other host? If so, you need to dump and reload the database alongside the application, using pg_dump -Fc and pg_restore. You can automate this within your application / build system using tools like ProcessBuilder, or do it manually.
There's no generic, canned way to do this. It'll require you to define an application deployment procedure, maybe produce an installer, etc.
We are looking at our current Liferay deployment for improvement in the near future. We'd like to move to where we use instances more.
We currently have a few sites in the default instance. The model we'd like to follow in the future is to - use the default instance for super/global administrator use only. Then create instances with different domains for different audiences/users and that they can be administered by different administrators/groups separately.
Does anyone know how can we move our sites and its related data to another Liferay instance? Is this easy and doable? Are there clearly defined steps and options for this process? Are there any risks to moving the data?
Thanks for the insight.
instances mean that there's nothing shared between the sites. Well, there actually is something: As you're running on the same appserver, so you're sharing all the code, all plugins.
For this reason you might not be as isolated as you want to be. Administration typically is a bit more tricky, as every single instance needs its own virtual host and its own user database (or LDAP connection). The shared plugins might limit you as to what customization you can do with Liferay.
Quite a few times I've seen expectations to "restart" the instance, which seems legit, as a customer is the only one on that instance. However, this quickly leads to accumulated maintenance windows for all instances that are not clearly visible to other customers.
In general you can use site's import and export, e.g. export to a LAR file and import into a new site on a new server in a different instance. You'll find the Import/Export UI in the site administration UI, along with the page administration.
What are the possibilities to distribute data selectively?
I explain my question with an example.
Consider a central database that holds all the data. This database is located in a certain geographical location.
Application A needs a subset of the information present in the central database. Also, application A may be located in a geographical location different (and maybe far) from the one where the central database is located.
So, I thought about creating a new database at the same location of application A that would contain a subset of information of the central database.
Which technology/product allow me to deploy such a configuration?
Thanks
Look for database replication. SQL Server can do this for sure, others (Oracle, MySQL, ...) should have it, too.
The idea is that the other location maintains a (subset) copy. Updates are exchanged incrementally. The way to treat conflicts depends on your application.
Most major database software such as MySql and SQL server can do the job, but it
is not a good model. With the growth of the application (traffic and users),
not only will you create a load on the central database server (which might be serving
other applications),but you will also be abusing your network bandwidth to transfer data
between the far away database and the application server.
A better model is to keep your data close to the application server, and use the far away
database for backup and recovery purposes only. You can use an FC\IP SAN (or any other
storage network architecture) as your storage network model, based on your applications' needs.
One big question that you didn't address is if Application A needs read-only access to the data or if it needs to be read-write.
The immediate concept that comes to mind when reading your requirements is sharding. In MySQL, this can be accomplished with partitioning. That being said, before you jump into partitions, make sure you read up on their pros and cons. There are instances where partitioning can slow things down if your indexes are not well chosen, or your partitioning scheme is not well thought out.
If your needs are read-only, then this should be a fairly simple solution. You can use MySQL in a Master-Slave context, and use App A off a slave. If you need read-write, then this becomes much more complex.
Depending on your write needs, you can split your reads to your slave, and your writes to the master, but that significantly adds complexity to your code structure (need to deal with multiple connections to multiple dbs). The advantage of this kind of layout is that you don't need to have complex DB infrastructure.
On the flip side, you can keep your code as is, and use a Master-Master replication in MySQL. Although not officially supported by Oracle, a lot of people have had success in this. A quick Google search will find you a huge list of blogs, howtos, etc. Just keep in mind that your code has to be properly written to support this (ex: you cannot use auto-increment fields for PKs, etc).
If you have cash to spend, then you can look at some of the more commercial offerings. Oracle DB and SQL Server both support this.
You can also use Block Based data replication, such as DRDB (and Mysql DRDB) to handle the replication between your nodes, but the problem you always will encounter is what happens if your link between the two nodes fails.
The biggest issue you will encounter is how to handle conflicting updates in 2 separate DB nodes. If your data is geographically dependent, then this may not be an issue for you.
Long story short, this is not an easy (or inexpensive) problem to resolve.
It's important to address the possibility of conflicts at the design phase anytime you are talking about replicating databases.
Moving on from that, SAP's Sybase Replication Server will allow you to do just that, either with Sybase database's or 3rd party databases.
In Sybase's world this is frequently called a corporate roll-up environment. There may be multiple geographically seperated databases each with a subset of data which they have primary control over. At the HQ, there is a server that contains all the various subsets in one repository. You can choose to replicate whole tables, or replicate based on values in individual rows/columns.
This keeps the databases in a loosely consistent state. Transaction rates, Geographic separation, and the latency that can be inherent to network will impact how quickly updates move from one database to another. If a network connection is temporarily down, Sybase Replication Server will queue up transaction, and send them as soon as the link comes back up, but the reliability and stability of the replication system will be affected by the stability of the network connection.
Again, as others have stated it's not cheap, but it's relatively straight forward to implement and maintain.
Disclaimer: I have worked for Sybase, and am still part of the SAP family of companies.
I need to create project in which there are two databases local and remote. Remote database needs to be synchronized daily with local database reflecting changes made in local database.
I am using JAVA. Database is ORACLE. I have JAVA/JPA code that does CRUD operations on local database.
How to synchronize changes to remote database.
I would not do this in Java, but look for native Oracle database synchronization mechanisms/tools. This will
be quicker to implement
be more robust
have faster replication events
be more 'correct'
Please look at some synchronization products. SQL Anywhere from Sybase where I work is one such product. You may be able to get a developer/evaluation copy that you can use to explore your options. I am sure Oracle has something similar too.
The basic idea is to be able to track the changes that have happened in the central database. This is typically done by keeping a timestamp for each row. During the synchronization, the remote database provides the last sync time and the server sends to it all rows that have changed since then. Note that the rows that have been deleted in the central database will need some special handling to ensure they get deleted from the remote database.
A true two-way synchronization is lot more complex. You need to also upload the changes from remote database to central and also some conflict resolution strategies have to be implemented for the cases when the same row has been changed in both the remote and central database in incompatible way in the two.
The general problem is too complex to be explained in a respone here but I hope I have been able to provide some useful pointers.
The problem is that what you are asking can range from moderately difficult (for a simple, not very robust system) to a very complex product that could keep a small team busy for a year depending on requirements.
That's why the other answers said "Find another way" (basically)
If you have to do this for a class assignment or something, it's possible but it probably won't be quick, robust or easy.
You need server software on each side, a way to translate unknown tables to data that can be transferred over the wire (along with enough meta-data to re-create it on the other side) and you'll probably want to track database changes (perhaps with a flag or timestamp) so that you don't have to send each record over every time.
It's a hard enough problem that we can't really help much. If I HAD to do that for a customer, I'd quote him at least a man year of work to get it even moderately reliable.
Good Luck
Oracle has a sophistication replication functionality to synchronise databases. Find out more..
From your comments it appears you're using the Oracle Lite: this supports replication, which is covered in the Lite documentation.
Never worked with it, but http://symmetricds.codehaus.org/ might be of use