Here is the official docs for Room Database. It contains the following code
val db = Room.databaseBuilder(
applicationContext,
AppDatabase::class.java, "database-name"
).build()
I was wondering what the "database-name" in the database builder does. What practical and tangible effects does it have?
Room is a Jetpack's wrapper on Sqlite DB. Sqlite holds data in single database file. So using "database-name" in Room's builder you'll get "database-name.db" file on filesystem.
In theory one app could deal with several SQLite databases. To switch between them you use different database names. If you have single database in your app its name isn't so crucial
Related
We are working in a very big organization, many Databases (of many types), many schemas, many users.
Does LB has to work with some Source Control (for locking the files
when many users exist in the organization and using the same DB,
same Schema, etc)?
What is the best practice of working with LB in a very big
organization, many concurrent users?
Can SQLCL general sql format type or just xml format type?
Is there some integration with SQL Developer? I mean, suppose a user
changes an objects via sql developer, what happens then?
We get this type of question all the time, after folks get a handle of how to automate DB changes, next step is typically to add it into an existing CI/CD workflow.
Yes, Liquibase works with any source control. Most users are using
Git. But you can use Git, TFS, SVN, CVS... Once you are up and
running with Liquibase, you just need to make sure that your scripts
are in source control and you are good to go.
Besides 3rd party source control tools, Liquibase has tracking tables called "DATABASECHANGELOG" tables that keep track of the changes applied to your database when using Liquibase deployments.
Here is some more information about getting started and How Liquibase Works. https://www.liquibase.org/get_started/how-lb-works.html
Liquibase has one more table that it uses internally called "DATABASECHANGELOGLOCK" table.
This table was designed to prevent multiple Liquibase users running deployments concurrently - potentially leaving the Database in a bad state. Once the Liquibase deployment (the liquibase update command) is done, the "DATABASECHANGELOGLOCK" will allow the next Liquibase user to deploy.
You can use both SQL and XML formats (or even JSON and YAML formats).
When using SQL, you have a few options:
Best option is to use Formatted SQL changeLogs https://www.liquibase.org/documentation/sql_format.html
https://www.liquibase.org/get_started/quickstart_sql.html
You can use plain raw SQL files referenced from an XML changeLog
https://www.liquibase.org/documentation/changes/sql_file.html
When using XML, can find all the available change types (also called changeSets) available in the following page (on the left of the page)
https://www.liquibase.org/documentation/changes/
XML changeLog are more agnostic and sometimes can be used for different Database platforms when doing migrations. Also, many of the change types in XML have the ability to be rolled back automatically. The reason that this is possible with XML is because Liquibase uses it own built in functions to figure out inverse statements like "create table" to be "drop table".
For each of those changeSets you can find out if they are auto rollback eligible (at the bottom of the page). For example, create table changeSet will be Auto Rollback = yes.
https://www.liquibase.org/documentation/changes/create_table.html
Let's imagine a standard situation.
Having the current DB schema in a working state, I would like to create a snapshot of this state of schema objects, name it SNAP_1.
Then if updated schema and got problems (bugs or unstable work of new code) it would be good to switch quickly - in one command - the whole schema code back to SNAP_1.
I'm wondering is there any built-in feature of Oracle DBMS for versioning:
PL/SQL code (schema objects)
Data (for example, within configuration tables)
Does Oracle DBMS give native tools for versioning at least one of these two?
The answer is no. But Oracle 11.2+ has something called "Editions".
This method has many restrictions. For example, data and table structure cannot be versioned.
Cool thing is that separate sessions can use a different version of the DB objects simultaneously. (package before fix and after fix)
Here is oracle's documentation.EDITION and
Examples of editions
I have an ERP application running with Oracle forms and Oracle database. Now I am planning to migrate this application to a java based enterprise application. will it be a good idea to keep the existing oracle database as back end and developing a web application with certain level of changes/additions in the DB design.
There are two facts to know before answer your questions:
has your database schema some oracle forms special structures or is it in 3rd normal form and simply stores data using keys and enforced referential integrity?
How much stored code contains your database?
Ad 1. Oracle forms don't have specific schema reqiurements. They work best if your schema if based on 3rd normal form. If your schema is like this, use it for new Java application. We have both forms and Java EE applications on same database schemas and is works fine.
Advantage is, if you have keys (primary, unique, foreign) in your schema. Use them when generating Java app.
Probably you will have to add #Version columns for optimistic locking (see https://docs.oracle.com/javaee/6/api/javax/persistence/Version.html). But there is not reason to build new schema for it.
Ad 2. Your will have to overwrite bigger part of database stored code (triggers, procedures, functions) to Java. In most cases this does not have dramatic impact to schema structure, but deal with it.
So - if your database schema is not tailored to some UI client needs AND you want only use a new client, use your schema. If not, create a new one.
I want to ask if I had a proper design. Background:I develop my web application with EF4. The application will be used by three offices. The business processes in the three offices is similar with each other. Each office has the database their own, but most tables, SPROCs in the databases are the same.My thinking:I want to extract the same tables and stored procedure to a single edmx file, and point the connection string to database at runtime basing on the logon user.
I add a method to the constructor
MPREntities(string connectionString, string containerName)
And will pass the connectionString and the container name, when initializing the MPREntities. The containerName is the same - "MPREntities", it does not depend on the databases pointed to. The connectionString will be changed according to the logon user before passing in. I have done some testing and seems it works. But is that a normal approach? any suggestions?
That approach will work, and is a good use case for this.
I have 2 databases, Oracle and SQlite. And I want to create exact copies of some of the Oracle tables in SQLite in one of my applications. Most of these tables contains more than 10,000 rows so copying each table by going through each row programmatically is not efficient. Also the table structure may change in the future so I want to achieve this using a generic way without hard-coding the SQL statements. Is there a any way to do this?
p.s. - This application is being developed using Qt framework. All the queries and databases are represented by QtSql module objects.
Can't help with Qt framework, but for large amounts of data is is usually better to use bulk-copy operations.
Export data from Oracle
http://download.oracle.com/docs/cd/B25329_01/doc/admin.102/b25107/impexp.htm#BCEGAFAB
Import data into SQLite
http://www.sqlite.org/cvstrac/wiki?p=ImportingFiles
IHTH
What you probably really want to use is the Oracle Database Mobile Server, which can automatically synchronize a SQLite and an Oracle Database.
The recent release of the Oracle Database Mobile Server (formally called Oracle Database Lite Mobile Server) supports synchronization between an Oracle Database and a SQLite or a Berkeley DB database running on the client. It supports both synchronous and asynchronous data exchange, as well as secure communications between client and server. You can configure the Mobile Server to synchronize based on several options without the need to modify the application that is accessing the database.
You can also find an excellent discussion forum for questions from developers and implementers using the Mobile Server.