I am presently building a Spring Boot backend with REST APIs, which is backed by Neo4j Database. So, while going through the official documentations of Spring Data Neo4j I have observed the usage of ReactiveNeo4jRepository and Neo4jRepository as data repositories for interacting with Database through our program.
But even going through the limited documentation many times I am unable to figure out how to distinguish among them? Kindly help me make this distinction.
Linear programming and reactive programming are two different concepts both in their operating logic as well as in the libraries with which the data that is returned from the database is worked with.
In neo4j the reactive interface works with two functions, one to return a single piece of data and another for when the return of a list of data is expected, since they are operated differently.
It is also always advised while technically not prohibited, it is not recommended mixing imperative and reactive database access in the same application.
Regards
This is the library for the import:
Imperative
Neo4jRepository
org.springframework.data.repository.Repository
org.springframework.data.repository.CrudRepository
Reactive
ReactiveNeo4jRepository
org.springframework.data.repository.reactive.ReactiveCrudRepository
org.springframework.data.repository.reactive.ReactiveSortingRepository
Related
Scenario :
I am having an application where I am using AWS Lambdas which are written in Kotlin to query data from a relational DB residing in AWS.
--
My problem is that I want to use an ORM for firing these queries. I dont want to use hibernate as it is too heavy and takes too long to setup, and I need a solution that would take up the least time in setting up and firing from the Lambdas. I have looked upon multiple ORMSs like Exposed, Requery, Jooq, Ktorm and Squash.
Is anybody out there having experience with any of these libraries in the serverless context? What are your experiences with them and what would you suggest using in my scenario?
You can have a look at exposed, https://github.com/JetBrains/Exposed
I have been using Squash with the Hikari connection pool for some large projects and I have been very happy with it. I like that is is very extensible and my team has been able to solve any issues that come up, implementing extensions to the dialect and the simplicity of defining TableDefinition classes makes it work well for generating code. It is also very self contained with very few dependencies and light on reflection, so should be good for serverless though I have not personally used it for that.
Squash is less an ORM than an sql abstraction / translation layer that ties into entities and it doesn't try to solve all the problems that something like hibernate does. In my experience ORMs start as simple, efficient, and powerful projects and grow to heavyweight libraries that try to do too much and their complexity begins to cause issues when the developer cannot easily see what's going on in the chain from usage through to the database / storage mechanism.
One negative about squash that deserves mention is that, while it is a jetlbrains official library and created by a kotlin developer, support is limited as orangy, the creator, is quite busy and I have feature pull requests outstanding, with many more of them backed up currently. I chose it because I favored it's simplicity and extensibility among a small but advanced team of developers all capable of improving upon it.
Which ever library you choose I hope these factors assist you in making your decision at the least.
I am building an application for iOS that has to be able to run offline and able to hold a number of tables, but also being to retrieve data easily. Which local database option would be more beneficial to a React Native beginner?
I know this question is already one year old, but I hope this helps someone. The database selection depends on the amount of data you are going to keep, PostgreSQL is out of the question and SQLite is quite good with local databases but it might be a pain to parse all your data into something SQLite can comprehend. Because of this, React Native has multiple ways of doing local storage (like AsyncStorage and LocalStorage), but for a beginner I would recommend other libraries to play with those resources:
redux-persist: If you are using redux, this library can be perfect for you, because with the autoRehydratation feature, you don't have to worry about anything but the initial setup. This library will save all your store as it is inside the mobile. You can setup which reducers to blacklist or whitelist, or even program some more advanced features for optimization.
Realm: Quite an awesome library, and my personal favorite. It allows you to manage models and queries, with which it will insert or select data inside a local database. It is really fast and has some nifty tricks to improve the ListViews performance. It can be used alongside redux-persist, because your database elements won't be saved inside the store.
Both libraries are excellent and I am sure there are even more out there, but I have only tried those two. I recommend you to read Tackling React Native Storage by Eric Kim, so you meet some really useful concepts, code examples and other libraries involving local storage.
I'm not actually even sure if PostGreSQL is an option (I found zero components). If you have information on how to use this on RN, please share.
As far as I'm aware, SQLite is the man! There are several options here...
https://react.parts/native?search=sqlite
RocksDB may also be an option. I've seen some use of that lately, but I think it's mainly just an abstraction for AsyncStorage. I could totally be wrong here as I've not looked to deeply into it.
https://gist.github.com/sahrens/ae3ad0889c608ecd51aa
We want to implement an API, we have a database located on a central server, and a network of many computers.
On these computers, several local programs will be developed in the future using different programming languages, some in java, some in perl, C++, ... etc.
These local programs should be able to access the API functions and interact with the database.
So in what language should the API be written ? so that it would be binding to the other languages. Is there any specific architecture that should be implemented ?
Is there any link that would provide useful information about this ?
If the API is pure database access, then a REST web service is a reasonable choice. It allows a (reasonably) easy interface from almost any language, and allows you to choose whatever language you feel is best for writing the actual web service. However, in doing it this way, you're paying the cost of an extra network call per API call. If you put the web service on the same host (or local network) as the database, you can minimize the cost of the network call from the web service to the database, which mitigates the cost of the extra call to the API.
If the API has business logic in it, there's two via approaches...
You can write the API as a library that can be used from multiple languages. C is a good choice for this because most languages can link C libraries, but the languages you expect to use it from can have a large impact, too. For example, if you know it's always going to be used by a language hosted on the JVM, the any JVM language it probably a reasonably good choice.
Another choice is to use a hybrid of the two. A REST API for database access, plus a business layer library written in multiple languages. The idea being that you have business logic on the application end, but it's simple enough that you can write a "client library" in multiple languages that knows how to call out to the REST API and then apply business logic to the results it gets back. Assuming the business logic isn't too complex (ie, limited to ways to merge/view the database data), then this isn't a bad solution.
The benefit is that it should be relatively easy to supply one "default" library that can be used by many languages, plus other language specific versions of the library where you have time available to implement them. For cases where figuring out what calls need to be made to the database, and how to combine the results, can be complicated, I find this to be a reasonably good solution.
I would resort to webservices. Doesn't matter what language you use as long as you have a framework to interact with webservices you are good. Depending on your needs you could expose a simple REST API or go all the way with SOAP/WSDL and the likes.
I am developing a transactional application in .NET and would like to get some input on how to properly encapsulate database access so that:
I don't have connection strings all
over the place
Multiple calls to the same stored
procedure from different functions
or WORSE, multiple stored
procedures that are different by a
single column
I am interested in knowing if using an ORM like NHibernate is useful, as it may just add another layer of complexity to a rapidly changing data model, and artifacts need to be produced on a tight schedule.
I am more interested in methods or patterns OTHER than ORM packages.
There are at least two widely accepted design patterns used to encapsulate data access:
repository (DDD)
DAO (Data Access Object)
For the sake of completeness I suggest you these books:
Patterns of Enterprise Application Architecture (Fowler)
Domain Driven Design (Evans)
If, as it appears, this is an important project and the DAL is a major risk factor, get someone involved who has done it before. You're exactly right that there are too many ways to run off the rails by trying to get this right the first time without solid experience.
There are any number of patterns for accomplishing this, but I'd look for someone who has a simple set of well-defined patterns they are fully comfortable with.
as stated above, check out the repository and unit of work patterns. the books by fowler and evans are highly recommended. so is karl seguin's reader which gave me a cooler introduction to the just mentioned books. grab it at http://codebetter.com/blogs/karlseguin/archive/2008/06/24/foundations-of-programming-ebook.aspx
As Java Developer, i could suggest to read about jdbc templates, despite of it s'n not .NET you could learn how Spring framework encapsulates data access tier and get some ideas.
I am continuing to delve into Erlang. I am thinking of starting my next web project using Erlang, and at this stage the only thing I will really miss from Ruby on Rails is ActiveRecord.
Is there a good alternative technology for Erlang?
Update:
The closest I have come to a solution is to ErlyDB, a component of ErlyWeb.
ErlyDB is a database abstraction layer
generator for Erlang. ErlyDB combines
database metadata and user-provided
metadata to generate functions that
let you perform common data access
operations in an intuitive manner. It
also provides a single API for working
with different database engines
(although currently, only MySQL is
supported), letting you write portable
data access code.
Well, the major advantages of ActiveRecord (as I see it) are:
You can persist your objects in a relational database nearly transparently.
You can search the database by any attribute of your objects.
You can validate objects when persisting them.
You can have callbacks on deleting, updating, or inserting objects.
With Mnesia:
You can persist any Erlang data absolutely transparently.
Using pattern matching, you can search the database by any attribute of your data or their combination.
QLC gives you a nice query interface for cases when pattern matching isn't enough.
No solutions for validating and callbacks, however...
So, what else do you have in ActiveRecord that is lacking in Mnesia?
I don't think there really is at the time of this writing. That may be because the kinds of systems being written in erlang and the type of people writing them don't really call for Relational Databases. I see much more code using mnesia, CouchDB, Tokyo Cabinet and other such alternative database technologies.
That's not to say someone might not want to create something like active record. It's just hasn't really been a need yet. Maybe you will be the first? :-)
You might be interested in Chicago Boss's "BossRecords":
http://www.chicagoboss.org/api-record.html
They are quite explicitly modeled on the Active Record pattern, and use a lot of compiler magic to make the syntax squeaky clean. BossRecords support save/validate as well as has_many/belongs_to associations. Attributes in your data model are made available through generated functions (e.g. "Employee:first_name()").
Some googling reveals libs / clients / wrappers for Couchdb described "ActiveRecord like libraries like CouchFoo", and advise to steer clear:
http://upstream-berlin.com/2009/03/31/the-case-of-activerecord-vs-couchdb/
http://debasishg.blogspot.com/2009/04/framework-inertia-couchdb-and-case-of.html#
as to your comment on "not suited for web apps yet", I think the pieces are there: mochiweb, couch, yaws, nitrogen, erlyweb. There's some powerful tools, very different paradigm, certainly, from rails, django and PHP.