I'd like to access an existing postgres database, which is on my local (mac) machine, from haskell.
I can see quite a few postgres packages on hackage. Which is likely to be the easiest for me to use?
postgresql-simple, a binding to libpq, was just announced, and seems to have a nice feature set. I haven't used it myself (or indeed PostgreSQL from Haskell at all), but it seems to have community support, so I'd recommend it if you don't want to use a particular library on top (like HDBC or persistent).
The alternatives appear to be libpq (another binding to libpq), which postgre-simple is based on, and pgsql-simple (a direct implementation of the wire protocol in Haskell), which, going by the post, doesn't seem ready for prime-time yet, and is not on Hackage.
There is also a PostgreSQL driver for HDBC; the PostgreSQL backend for the persistent library (as used in Yesod) is based on it.
Opaleye is a higher-level alternative to postgresql-simple. It uses postgresql-simple under the hood but provides a typesafe and composable API.
http://hackage.haskell.org/package/opaleye
Related
I am developing a new project with spring boot and graphql. I am confused on how to proceed because there are 2 ways to develop it, one is via the graphqls file and Annotation based approach. I prefer Annotation based approach but are they stable. exmaple : https://github.com/leangen/graphql-spqr.
I second AllirionX's answer and just want to add a few details.
Firstly, to answer your question: yes, SPQR has been pretty stable for quite a while now. Many teams are successfully using it in production. The only reason it is still in 0.X versions is the lack of documentation, but an occasional small breaking change in the API does occur.
Secondly, I'd also like to add that going code-first doesn't mean you can't also go contract-first. In fact, I'd argue you should still develop in that style. The only difference is that you get to write your contracts as Java interfaces instead of a new language.
As I highlight in SPQR's README:
Note that developing in the code-first style is still effectively
schema-first, the difference is that you develop your schema not in
yet another language, but in Java, with your IDE, the compiler and all
your tools helping you. Breaking changes to the schema mean the
compilation will fail. No need for linters or other fragile hacks.
So whether the API (as described by the interfaces) changes as the other code changes is entirely up to you. And if you need the SDL for any reason, it can always be generated from the executable schema or the introspection result.
I don't think there is a good or a bad answer to the "how to proceed" question.
There are two different approaches to build your graphql server (with graphl-java, graphql-java-tools, graphql-spqr), and each method has its advantages and inconvenients. All those library propose a springboot starter. Note that I never used graphql-spqr.
Schema first (with graphql-java or graphql-java-tools)
In this approach you first create a SDL file. The graphql library will parse it, and "all" you have to do is wire each graphql type to its data fetcher. The graphql-java-tools can even do the wiring for you.
Advantage
no need to enter into the detail of how the Graphql schema is built server side
you have a nice graphqls schema file that can be read and used by a client, easying the charge of building a graphql client
you actually define your api first (SDL schema): changing the implementation of the api will not require any change client side
Inconvenient
no compile-time check. If something is not wired properly, an exception will be thrown at runtime. But this can be negated by using graphql-java-codegen that will generate for you the java classes and interfaces for your graphql types, unions, queries, enums, etc.
if using graphql-java (no auto wiring), I felt I had to write long boring data fetchers. So I switched to graphql-java-tools.
Code first (with graphql-java or grapqhl-java-tools or graphql-spqr)
The graphql schema is built programmatically (through annotation with graphql-spqr or by building a GraphQLSchema object in graphql-java)
Advantage
compile-time check
no need to maintain both the SDL and the Domain class
Inconvenient
as your schema is generated from your code base, changing your code base will change the api, which might not be great for the clients depending on it.
This is my opinion on those different framework and I would be happy to be shown that I am in the wrong. The ultimate decision depends on your project: the size, if there is an existing code base, etc.
I have a java codebase that seems to be using "com.google.api.services.cloudkms.v1.CloudKMS" to call KMS. The online docs says to use "com.google.cloud.kms.v1.KeyManagementServiceClient"
When i looked up both packages seem to be updated, however the reference docs recommend using the latter.
https://developers.google.com/resources/api-libraries/documentation/cloudkms/v1/java/latest/com/google/api/services/cloudkms/v1/CloudKMS.html
https://cloud.google.com/kms/docs/reference/libraries
Could someone tell me what is the difference between these 2 clients packages and if i should move to the one the reference links to?
In general, you should prefer the library referenced on the Reference Libraries page, currently com.google.cloud.kms. The examples and tutorials on the website will use this client library.
Probably more history than you need to know, but we have two client libraries because they run over different protocols. The new libraries (the one's listed on the reference page) use gRPC to communicate. This means less bandwidth and less time spent serializing/de-serializing JSON. On the flip side, gRPC requires HTTP/2, and some organizations can't/won't support HTTP/2 yet. As a result, we still publish and maintain legacy libraries that are REST over HTTP/1. It is strongly recommended you use the gRPC ones unless you can't use HTTP/2.
You can read more about the background and technical details in Kickstart your cryptography with new Cloud KMS client libraries and samples.
Looking at the MongoDB project, it seems to have many drivers. It has a C Driver, Java Driver, Ruby Driver, etc...
How are these different from client libraries? It seems that each of those provide an interface to use the product (in this case MongoDB) from one of those languages.
Is there a technical difference between the two terms?
Thanks!
An application communicates with MongoDB by way of a client library, called a driver, that handles all interaction with the database in a language appropriate to the application.
Source: https://docs.mongodb.org/manual/applications/drivers/
I could be totally misunderstanding Entity Framework here. I want to use that in my latest project (how else do you learn?) The problem is that the IBM i driver doesn't have support for that built in. Is is possible to create that framework from scratch? It is worth it?
It sounds like you'd be writing your own ADO.NET data provider to connect to IBM DB2 for i. Microsoft provides documentation for creating your own provider and a sample.
The data provider would be responsible for communicating with the database, so I'm not sure how you'd accomplish that. Either you'd be implementing your own connection to the database server running on the i (maybe you can port the SQL piece of JTOpen), or you'd be delegating your calls to the IBM-provided data provider (if that's even possible) or other data access method.
I couldn't decide whether I thought this was (1) a huge pain in the butt or (2) an opportunity for an open source project. (I guess it could be both.) It seems like it'd be easier to lobby IBM to make this part of their stock provider. You might complain about it on MIDRANGE-L and see if people will take up the cause.
Disclaimer: I am a newbie in the .NET world, so maybe there's an easier way to accomplish what you're trying to do.
I am trying to use Class::DBI with Catalyst::Plugin::Authentication::Store::DBIC. The example given on CPAN does not work with Class::DBI. For example, the config is incorrect: role_class => 'DB::Role' has to be replaced by role_class => 'MyApp::Model::DB::Role' I got Authentication working using plain DBI, but I would rather use Class::DBI like in the rest of my application.
I could not find a complete example of Catalyst authentication with Class:DBI. Do you know any such tutorial?
I suspect you'd be better off asking about this on the #catalyst channel on irc.perl.org. You'll either end up writing your own store for CDBI, or you'll work out how to use the CDBI compatibility layer in DBIx::Class to get it working, or if it's a new codebase, then you should really consider CDBI legacy and build your schema with DBIx::Class and DBIx::Class::Schema::Loader
I hate to say it, but singingfish is right. The Catalyst::Plugin::Authentication::Store::DBIC has not been updated in some time (aside from being made to display the deprecated warning) It also uses the old (2006) authentication API and will be the limiting factor of your application even if you did get it to work.
If you have the option, I would switch to DBIx::Class. If not, your only real choice is to write your own user storage module that works with Class::DBI. It's actually not too hard and you can find instructions in the internals doc for Catalyst Auth:
http://search.cpan.org/dist/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication/Internals.pod
Good luck!
JayK