We are wondering what might be the best way to use micronaut-data to connect to BigQuery. BigQuery has a rather poor JDBC support and in addition it does not support transactions while micronaut-data enforces transactions.
Is there a way in the micronaut-data API to add an Annotation #BigQueryRepository and provide the annotation processor with information on how to generate the access to the database and how to generate queries?
Or would it be the correct way to just implement the CrudRepository interface and provide everything else on our own?
Or is micronaut-data just not the right tool to use here?
We are trying to get a feeling about if it would be a better way to extend micronaut-data or to implement it outside of micronaut-data.
Is there a way in the micronaut-data API to add an Annotation
#BigQueryRepository and provide the annotation processor with
information on how to generate the access to the database and how to
generate queries?
Quite likely, yes we could developer support like that.
Or would it be the correct way to just implement the CrudRepository
interface and provide everything else on our own?
You could write all of on on your own of course. I don't think Micronaut Data would be provided a whole lot at that point.
Or is micronaut-data just not the right tool to use here?
In its current state I don't think micronaut-data adds much for this scenario but that doesn't mean that it won't in the future.
You may take a look at our new Micronaut BigQuery library
https://agorapulse.github.io/micronaut-bigquery/
It allows you to run the basic SQL and it provides a mock implementation for testing.
Related
I've done some research into the subject of response serialization for NestJS/GraphQL. There's some helpful information to be found here, but the documentation seems to be completely focused on a code first approach. My project happens to be taking schema first approach, and from what I've read across a few sources, the option available for a schema-first project would be to implement interceptors for the resolvers, and carry out the serialization there.
Before I run off and start writing these interceptors, my question is this; is there any better options provided by nestjs to implement serialization for a schema first approach?
If it's just transformation of values then an interceptor is a great tool for that. Everything shown for "code-first" should work for "schema-first" in terms of high level ideas of the framework (interceptors, pipes, filters, etc). In fact, once the server is running, there shouldn't be a distinguishable difference between the two approaches, and how they operate. The big thing you'd need to be concerned with is that you won't be easily able to take advantage of class-transformer and class-validator because the original class definitions are created via the gql-codegen, but you can still extend those types and add on the decorators necessary if you choose.
I am trying to build a federated RDF application based on rdf4j and FedX. What I need is to be able to:
Optimize the querying plan and joining strategies.
To expose different and heterogeneous databases (A timeseries or a relational DB for example) in a federated fashion.
I went a little bit through the rdf4j documentation and I got a grasp. And therefore I have some little questions:
Is there any documentation that explains how to implement the SAIL API? I tried to debug and follow the flow of execution of an example query using a RDF memory store and I got lost.
Suppose I want to expose a relational database in my datacenter, Should I implement a SPARQL repository or an HTTP repository? should I in anyway implement the SAIL api?
Concerning fedX, how can I make it possible to use the SERVICE and VALUES terms as proposed in the SPARQL 1.1 federated queries? How can I change the Joning strategies? the query plan?
I know that this can be answered if I dive deeply into the code but I wonder if someone has already exposed some kind of a database using the rdf4j API or even worked and tuned RDF4J.
Thanks to you all!
Is there any documentation that explains how to implement the SAIL API? I tried to debug and follow the flow of execution of an example
query using a RDF memory store and I got lost.
There is a basic design draft but it's incomplete. A more comprehensive HowTo has been in the planning for a while but it never quite gets the priority it needs.
That said, I don't think you need to implement your own SAIL for what you have in mind. There's plenty of existing implementations that can do what you need.
Suppose I want to expose a relational database in my datacenter, Should I implement a SPARQL repository or an HTTP repository?
I don't understand the question. HTTPRepository is a client-side proxy for an RDF4J Server. SPARQLRepository is a client-side proxy for a (non-RDF4J) SPARQL endpoint. Neither has anything to do with relational database.
should I in anyway implement the SAIL api?
It depends on your use case, but I doubt it - at least not right at the outset. I'd probably use an existing R2RML library that is compatible with RDF4J, like for example the R2RML API, or CARML - either a live mapping or an offline batch mapping between the relational data and your triplestore may solve your problem.
Concerning fedX, how can I make it possible to use the SERVICE and VALUES terms as proposed in the SPARQL 1.1 federated queries?
You don't need to "make it possible" to do that, FedX supports this out of the box.
How can I change the Joning strategies? the query plan?
You can't (at least not easily), nor should you want to. Quite a lot of research and development went into RDF4J's and FedX query planning strategies. I'm not saying either is perfect, but you're unlikely to do better.
I am wanting to setup a REST API with a legacy database. I am looking into LINQ to SQL as an option to be the communicator between the database and the REST API. The order of operations are as follows: client will request data from REST API, REST API receives the "GET" request, calls LINQ to SQL method to get the object requested, object is returned in JSON format to client for client-side processing. I like LINQ to SQL because it can take a data table and spit out a C# object.
Most of the requests will be "GET"; however, in the future "POST" and "PUT" will be added.
Is this reasonable, or should I look to a different method? I am a new developer, so please excuse my ignorance!
The particular technologies that you use are just tools that help you achieve a goal. A means to an end. That goal is typically to solve some business problem. It is also good to do so in a robust, flexible and easily extensible way so as to provide the most possible business value in the least amount of time.
If one were to analyze an aspect of your question, using LINQ to SQL is fine. However, there are any number of ORM solutions that would accomplish a similar result (nHibernate, Entity Framework, ADO.NET). They all can achieve the goal of solving the business problem.
The important thing to remember is that the specific technology you choose for an implementation is typically not nearly as important as how you go about implementing the solution. Good and bad code are independent of technology they are written in.
In summary, the technologies that you listed in your question are all excellent technologies that can provide robust, flexible, and easily extensible solutions when used properly.
I'm experimenting with the new Umbraco 5 hive, and I'm kinda a bit confused.
I'm plugging in an existing Linq to SQL services layer, which I developed for a webforms site.
I don't know much about the repository pattern, my services handle all connections with the data context, and work very well.
I have made a few repositories that plug in to the hive, and handle conversion of my entities to the Umbraco TypedEntity type.
These repositiories reference my existing services layer, to retrieve, add, update and delete. The services also handle other entity specific functions, which will not be used by the hive.
Now, it's nice to plug in these services, and just reference them in the hive repositories, but it seems I may be doing things the wrong way round, according to the offical repository pattern as I have read about.
I know there's no hard fast rules, but I would appreciate comments on what I'm doing to achieve this functionality.
I've asked this here instead of the Umbraco forum, as I want a wider perspective.
Cheers.
I personally feel that the Hive is overkill. With the ability to use your own classes directly within razor macros, I think the best approach is to forego the hive altogether and simply use your classes. Why would you trade all of the power of your existing service just to make it fit into the hive interface?
If you're writing a library for other Umbraco developers, you may need to do this, but it's my personal opinion that the hive is over-engineered at worst and a layer of abstraction aimed at newish developers at best.
So, if I were to advise you, I would say to consider the more general principles: "Keep It Simple" and "You Aren't Gonna Need It". If the interface they give you offers a tangible benefit, implement it. If not, consider what you really gain for all of that work.
For a simple example, let's say you create guestbook in your site and you plan to give external access for Create and Read functions via API. Update and Delete will not be included in the API since it should only be used internally.
What's a better practice?
Make the whole CRUD functions available via API and just restrict public access to Update and Delete. So you yourself will also use the API for all internal workings of the app.
Make internal CRUD functions without API for all internal workings, then create a separate API for Create and Read only. Basically this give you two ways to use Create and Read - one with API, one without.
Make internal Update and Delete functions without API for internal workings, then create API for Create and Read only. If you need to use Create and Read functions for internal workings, then you must use API.
I hope it's quite clear, what's generally the best practice?
I like the first option. It has a clear example of separation of concerns and using right tools in the right context.
By using CRUD approach for the API, you gain uniformity and integrity. It results in a more cohesive design, less code duplication and easier evolution down the road. The security aspect could be implemented either inside or outside of the application powering the API. For the outside option you could use 3-d party software or hardware solutions like firewalls, for example.