I have created a JPA desktop application with MySQL as DB. And I have configured the persistence.xml file as, it will create the tables in DB, if the tables are not already present (<property name="eclipselink.ddl-generation" value="create-or-extend-tables" />). This application is working fine so far. But, I am planning to publish this application in Cloud, so that everyone can get benefit of this application.
My assumption is, when it gets popular (being optimistic), I believe, the data will grow to greater extend. So I am planning to use NoSQL instead of RDBMS for scalability purpose. But I am not a NoSQL developer so far.
My Question is, Can I reuse the existing JPA2.0 Entities (auto-generated code, created using EclipseLink in Eclipse neon) pointing to NoSQL, by simply changing the values in persistence.xml file? Will it work as it is working currently?
Related
I'm integrating SQL database (PostgreSQL) into my first ever Java backend system.
My dilemma now is should the application create the database and the tables by itself, or should it just assume that the required database initialized with the tables will be available?
If the application should not manage the database by itself, then what's the best approach to reproducing the database on developers' machines (I want to be able to run integration tests with real database locally)?
I ended up using FlyWay as #Max suggested in his comment.
The setup was quite easy and intuitive. I used the default settings for time being.
Setup of integration testing on development machine was a breeze.
The only thing that I don't particularly like is that cleaning the database between tests using FlyWay is very slow because it doesn't just clean the tables, but erases the entire scheme.
This, however, is not a big issue for me right now (currently have ~100 tests), and, probably, will not be difficult to optimize in the future if needed.
I have legacy code that has DB connected.I'm trying to add new features for this app with Symfony2. I used Theodo Evolution Bundle to access the legacy session.
First thing that I want to do now, is to build an API that will use data from existing database. This database has tables that are not converted to entities. My question is which is best approach in this case. To use native queries from existing tables in database to build API or to convert tables into entities I used documentation for this part but I'm not sure will import all relations and everything) and then to build API. Can you please suggest me which is best approach in this case. Thank you.
The best approach in my opinion is to work with doctrine entities within the framework and to avoid direct SQL if possible. That is the basic philosophy behind frameworks such as Symfony: the database layer should be abstracted.
The entity-database mapping might be quite more of a hassle at first, because you can't rely on automatic tools to set it up, but once it's done it will be much easier to work out the rest of the application.
When I started to code my sinatra application I never used it before. Note that I had and still have no experience with RoR. I had one .rb file and one .haml and was happy. Now I had to split .rb file into about 10 'library' files as the whole application gets more and more complex.
I store some application logs/info in csv files and now I am getting conflicts when accessing the csv file. So I think that I need to introduce "proper" database solution. I want it to be part of my ruby (sinatra) application.
How can I introduce 'light' sql database into my sintra application?
I am on ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mingw32] soon upgrading to 1.9 (hopefully)
I'd recommend looking at Sequel. It's very flexible and powerful, and works well with SQLite, MySQL, Postgres, Oracle and other DBMs. It's not opinionated about how you talk to the database; You can use it as an ORM or with simple datasets, and allows embedded SQL or more programmatic approaches.
For ORM, both ActiveRecord and Sequel are recommended. About database, I guess sqlite3 will be good enough for your need. Also you can choose mysql or pg.
If you want to use active_record, you'll find this article very useful.
And if Sequel is the choice, just read Sequel documents here.
After the gems installed. You can start writing some code to connect the db. Then maybe some migration task to build database tables (and don't forget build some corresponding models). Both gem have similar syntax for migrations. After that, import your csv data and well done.
I have had no trouble using either Active Record or DataMapper to add object persistence to my Sinatra apps. People also tell me Sequel is very good but philosophically it is not not worlds apart from Active Record imho.
Active Record and Sequel favour a more database-centric approach, whereby you spell out your tables as a set of database and table definitions in a collection of migration files and merge them into a schema which is then used to build or update your database tables. If you really care about the underlying SQL database then one of these is for you. I find them to be six of one, a half-dozen the other.
DataMapper is more object-centric and lets you define the properties and object relationships you need in your object's own class definition; and then when your app launches you make sure you call DataMapper.auto_upgrade! and it upgrades the database to suit your object graph. The upside is that you only have one place to look to find what properties your object might have. The downside is you have less control over the specifics of the underlying databases, though it's not impossible to tightly define the mappings, DataMapper works well when you care about object graphs over database tables.
The good news is they pretty much all work in the same way once you have your mappings from object graph to SQL database tables defined. All support lazy or pre-emptive loading of related collections of objects, many_to_many relationships, polymorphism, etc, and tend to vary only in configuration and seeding details.
I often start projects using DataMapper just for its speed of throwing up and tearing down database schemas, as the app's object graph is still in flux; I refactor quickly to use Active Record when the schema has settled down. Next project I think I'll give Sequel a go though, as people do seem to rave about it.
I have had success using datamapper with Sinatra, put like the other post you can also use Sequel and Active Record. One advantage to maybe using Active Record though is if you do ever want to use/learn ROR, Active Record is the default ORM so that might be something that you want to consider.
If you don't want to go the ORM route you can always use the SQL-Ruby gem which will allow you to create and run sql queries. Here is some example code from the website http://sqlite-ruby.rubyforge.org/
require 'sqlite'
db = SQLite::Database.new( "data.db" )
db.execute( "select * from table" ) do |row|
p row
end
db.close
I'm just getting underway with Orchard CMS. How difficult would it be to create an Orchard module that uses RavenDB as its database? Is a hard dependency on SQL and NHibernate baked deeply into Orchard?
All of Orchard's core features are based on NHibernate so it would be difficult to move the entire Orchard database to another DBMS not supported by NHibernate. However, Orchard is very extensible and it is quite easy to access all kinds of custom data sources from your own modules. For example, I am currently working in a project where we store our data in a graph database (neo4j) and access them in Orchard using a WCF service.
It depends on what kind of data you need to access, but you will probably need to create a custom content part which dynamically loads data instead of using the underlying SQL database through NHibernate. You can do this by inheriting from the non-generic ContentPart class (the generic one uses a record stored using NHibernate) and using a ContentHandler to populate the data from your custom data source.
There is an experimental RavenDB-based data layer implementation in 'ravendb' Mercurial branch.
It was built a couple of months ago and I'm not sure about the compatibility with the current release, but you can give it a try. There were no big changes to DL since then so I assume it should work or need just a couple of tweaks.
I'm now working with a legacy database which is missing, among almost everything you'd expect from a decent SQL relational DB, any documentation or metadata. I can't make changes to the DB schema, except my local test copy, as it exists at many client sites and there's no upgrading procedures. Are there any tools that I can use to build and keep my own meta about the database? I'm looking to keep track of relationships, basic documentation about tables and columns, and references in stored procedures. There's 200+ tables and 3300+ SPs. A base autogeneration would be very helpful, particularly with the SPs. Preferably FOSS and Linux, but I will settle for win just to have something.
Not sure what you mean with "metadata", but I'm pretty happy with Liquibase.
It manages the schema in one (or more) XML files and can reverse engineer an existing database (all major ones supported).
It's Java/JDBC based and runs fine on Linux
The main purposes of Liquibase is to handle upgrades (schema migration) smoothly, so I'm not sure if this exactly what you are looking for.