What is the difference between graphql and sql.
If in graphql we select all the tables and all the columns of each table.
And sql in the endpoint serve we evaluate the query that does not have sql injected for prevent update or delete.
Performance is better whit graphql?
Really safety if it is extremely safe with graphql?
GraphQL is not related to database, it's about the presentation layer, You can implement an API with that. for more information check the link bellow:
https://en.m.wikipedia.org/wiki/GraphQL
Related
As title says:
Should the query side of CQRS applications call the database direcly in the controllers/handlers and skip application services, domains and repositories?
What if the query logic is complex and/or I also need to publish an event (related to the read operation) to a message broker? In what layer would that logic fit?
The Query side will only contain the methods for getting data, so it can/should be really simple. The domain model from the command side is definitely not part of the query side. The queries are separate from the model we have in our domain. An abstraction on top of your persistence is not required too.
Simple query logic would make your life easier. The secret sauce of CQRS is polyglot persistence. You may maintain multiple denormalized representations of your data, also known as a materialized views, which are tailored to your query needs.You can have multiple projections on your data on different databases depending on your query needs. If you do that, the query side tends to become simple
e.g. if you have a projection of something that is an entity in your domain like a customer then you can persist it in Mongo and query it by id - really simple and performant, if you have some report with multiple orders you can persist those in a relational database and do sql queries - simple and performant. This way you would end up with GET queries that do database queries and return the read models without any additional mapping.
Having said that, I would like to state that this a typical use case, but your read models can also be slightly different queries on the same table of a db. This would make the query a bit more complex, but might be good enough too.
I also don't think that you should publish an event from the query side. What would that event be?
I'm looking for some resources to get me started on how to design and implement an API for SQL.
Is this done by writing a series of functions and/or stored procedures to process your transactions on the SQL server (T-SQL).
I have read a bit about Transaction API's v Table API's. While you don't have to chose one of the other I would prefer to avoid the Table API's and focus more on Transaction API's to keep performance high and avoid using cursors.
Also from what I understand RESTFUL API's are just making the requests through HTTP requests (Using JSON) rather than connecting to the DB directly.
If my understanding is completely wrong on this subject please correct me as I am trying to learn.
Thanks
I have an application in which I'd like to accept a user supplied SQL query from a front-end query builder (http://querybuilder.js.org/). That query eventually needs to make it's way to running in a postgres database to return a subset of data.
The query builder linked above can export SQL or a mongo query. I imagine using the mongo query is relatively safe, since I can add to it simply on the server:
query.owner_of_document = userId
to limit results (to documents owned by the user).
Whereas the SQL statement could potentially be hijacked in an injection attack if someone attempts to store a malicious string of SQL for execution.
Is directly accepting SQL from a client bad practice? How can I ensure the supplied SQL is safe?
Thanks!
Why do you need to accept an entire SQL statement?
Can you accept only parameters and then run a pre defined query?
There are loads of questions/answers on SO relating to SQL injection and using parameters is a first step in avoiding injection attacks, such as "Are Parameters really enough to prevent Sql injections?"
But I think this answer to a different question sums things up well:
Don't try to do security yourself. Use whatever trusted, industry
standard library there is available for what you're trying to do,
rather than trying to do it yourself. Whatever assumptions you make
about security, might be incorrect. As secure as your own approach may
look ... there's a risk you're overlooking something and do you
really want to take that chance when it comes to security?
I am trying to identify slow queries in a large-scale Django 1.3 web application. As it is kind of difficult to match the raw sql query in the slow query log with the specific ORM statement in the code, I wondered if it is possible to add a SQL comment to the query constructed with the ORM, something like..
Object.objects.filter(Q(pub_date__lte=datetime.now)).comment('query no. 123')
Solution found by using .extra() for raw SQL commands on the django-user mailinglist:
Object.objects.filter(Q(pub_date__lte=datetime.now()).extra(where=['1=1 /* query no. 123 */'])
For those reading in 2022 onwards - there is a much better answer these days:
Google's sqlcommenter project has a Django middleware
[A] Django middleware whose purpose is to augment a SQL statement right before execution, with information about the controller and user code to help with later making database optimization decisions, after those statements are examined from the database server’s logs.
I would like to know whether is possible to add normal data to a Sesame Database using SQL queries and retrieve them through SQL queries..??
Do you mean adding new tables to the Sesame store so that you can store non-RDF data as well? If you use Sesame's RDBMS store, then it could be possible. But it is probably not such a good idea, because it would be very easy to mess up Sesame's internal schema and put the store into an inconsistent state.
If you use Sesame's native store, then it's not possible.