I'm trying to figure out the naming convention for parts of Cypher queries. In Cypher Query Language Reference, Version 9 DETACH is listed on page 197 as a clause.
But in all examples, I've seen DETACH used only in pairs with DELETE. So it is always DETACH DELETE.
MATCH (n)
DETACH DELETE n
or
MATCH (n {name: 'Andres'})
DETACH DELETE n
Does DETACH have any other purpose or can it be used only with DELETE?
The terminology does seem to vary a bit here depending on what you read.
I have seen DETACH described as a keyword in some documentation and posts, but in the openCypher specification DETACH and DETACH DELETE are each classified as clauses in the table of available clauses.
Regardless, as far as openCypher goes, and as far as I am aware, Cypher too, DETACH is only ever used with DELETE.
Related
I am using Sql-Server and Postgresql, usually when I need to run multiple commands, I open a new connection, and foreach needed query task I run a command (inserting 1000 rows, for example).
Is it bad if I run multiple query commands in a single command(queries separated by comma) vs previous behavior?
Running multiple commands inside a single call (and being able to do it) makes you extremely vulnerable to SQL injections. Any query, even a simple SELECT, becomes dangerous if somebody can append an UPDATE or DELETE statement afterwards. That's why many implementations (especially from PHP) simply inhibit the ability of submitting nested queries.
On the other hand, as far as I know, there's almost no valid reason to do so. One usually maintains the connection open, then the overhead implied by the call itself is negligible.
If what you seek is actually atomicity, then you want to try "transactions" instead ;
If you worried about the complexity of your queries and don't want to make them be re-parsed at each time, you may take a look to "prepared statements" and stored procedures (or "functions" if you're using a recent version of PostGreSQL).
Here in the company I work, we have a support tool that, among other things, provides a page that allows the user to run SELECT queries. It should prevent the user from running UPDATE, INSERT, DELETE, DROP, etc. Besides that, every select statement is accepted.
The way it works is by executing
SELECT * FROM (<query>)
so any statement besides a SELECT should fail due to a syntax error.
In my opinion, this approach is not enough to prevent an attack since anything could change the out-query and break the security. I affirmed that along with that solution it should also check the syntax of the inside query. My colleagues asked me to prove that the current solution is unsafe.
To test it, I tried to write something like
SELECT * from dual); DROP table users --
But it failed because of the ; character that is not accepted by the SQL connector.
So, is there any way to append a modification statement in a query like that?
By the way, it is Oracle SQL.
EDIT:
Just to put it more clear: I know this is not a good approach. But I must prove it to my colleagues to justify a code modification. Theoretical answers are good, but I think a real injection would be more efficient.
The protection is based on the idea/assumption that "update queries" are never going to produce a result table (which is what it would take to make it a valid sub-expression to your SELECT FROM (...) ).
Proprietary engines with proprietary language extensions might undermine that assumption. And although admittedly it still seems unlikely, in the world of proprietary extensions there really is some crazy stuff flying around so don't assume too lightly.
Maybe also beware of expression compilers that coerce "does not return a table" into "an empty table of some kind". You know. Because any system must do anything it can to make the user action succeed instead of fail/crash/...
And maybe also consider that if "query whatever you like" is really the function that is needed, then your DBMS most likely already has some tool or component that actually allows that ... (and is even designed specifically for the purpose).
I'm going to assume that it's deemed acceptable for users to see any data accessible from that account (as that is what this seems designed to do).
It's also fairly trivial to perform a Denial of Service with this, either with an inefficient query, or with select for update, which could be used to lock critical tables.
Oracle is a feature rich DB, and that means there is likely a variety of ways to run DML from within a query. You would need to find an inline PL/SQL function that allow you to perform DML or have other side effects. It will depend on the specific schema as to what packages are available - the XML DB packages have some mechanisms to run arbitrary SQL, the UTL_HTTP packages can often be used to launch network attacks, and the java functionality is quite powerful.
The correct way to protect against this is to use the DB security mechanisms - run this against a read-only schema (one with query privs only on the tables).
I want to run a series of SQL INSERT statements.
The problem is I want an all-or-nothing approach. Either they all execute or if one of them doesn't execute then no changes are made to the database.
The only solution i can think of is using a conditional loop but that would mean a lot of redundant code (determining changes made, dropping tables etc)
Is there a simpler solution?
I have searched extensively for a solution, but didnt find any similar questions, so apologies if it has been asked before
You need to use a Transaction, you can find an MSDN example here.
Fortunately, a good database is one that has the four ACID properties - Atomic, Consistent, Integrated and Durable.
The first property- Atomic - refers to the behavior of transactions where either the entire transaction is commited at a time or no changes take place at all.
Read Korth's book "Database System Concepts" for further reference.
If you are using an outstanding database like Oracle, MS SQL Server, MySQL, DB2, etc., all you have to do is study a little bit about how they handle transactions and place your DML statements within these transactions.
Find out about Oracle's transactions support here.
P.S.- Looks like you're working in banking domain. These people are hell-bent on these things.
I just have a very quick question about the use of compound triggers.
I'm very new to database/sql/oracle and have a uni task where i have had to create triggers for the following:
Insert into log table when sales person creates an order
Update on order table whe order is ready to ship (plus insert into log)
Prevent INSERT, UPDATE, DELETE after 5pm friday until 9am monday.
I have succesfully implemeted the triggers but have just become aware of the compound triggers in 11g. Would it be appropriate to look into combining the above into one complound trigger? Is that what they are for or am I missing the point?
Many thanks for looking at this rather vague question.
IMO it wouldn't be appropriate. A compound trigger allows you to trap the four different trigger points (before statement, before action, after action, and after statement) for a given action on a given table, but it looks like A) you're triggering on multiple tables, and B) you don't have a need to service all the different trigger points. (BTW, "action" as I've used it here can mean different statement types, e,g. BEFORE INSERT, UPDATE, DELETE...).
Compound triggers make for a nice, clean, and compact way to work around the never-popular ORA-04091 MUTATING TABLE error, but for the most part I don't find them necessary or useful as a general-purpose do-all replacement for "normal" triggers. For an example, see my answer to this question.
Share and enjoy.
wow - compound triggers - didn't know they even existed...
I quickly looked up the documentation
The main reason to use compound triggers is explained as follows:
The compound trigger makes it easier to program an approach where you
want the actions you implement for the various timing points to share
common data. To achieve the same effect with simple triggers, you had
to model the common state with an ancillary package. This approach was
both cumbersome to program and subject to memory leak when the
triggering statement caused an error and the after-statement trigger
did not fire.
So unless you needed package variables to implement your functionality there wouldn't be a reason for using them. And your code wouldn't be 10g compatible anymore.
Long ago I have learned sql and within the last years of application development I realized I only rarely really play with a real sql console or sql commands at all, especially since I mainly work with rails applications for a while now.
But right now I am working on getting a few Microsoft certifications, so for that I did end up relearning sql from scratch. And by that so many things come to mind that - I have to admit - I have forgotten over all the years. Yes, from a developers view, sql is important, but somehow I didn't need much of it... like stored procedures, functions, triggers, etc...
While I already found a nice blog from Nasir about using Views in Rails,
I am still wondering if I can use
functions
stored procedures
triggers
in Rails.
Triggers: Of course I wouldn't need do define triggers within a rails application. I would create them directly on the database management console. I'd just have to remember the things that are 'automatically' done. I would like to use those for logging purposes or pre-calculations of quick-access-tables ...
Functions: They should be easy to use I would think. Is it possible to add them via the 'select'-method of ActiveRecord?
Stored Procedures: How would one use those from Rails, i mean they could be valuable if you have several complex queries with multiple joins and calculation-based dependencies. I wonder a) how to call one and b) how to receive the results
Well, if you have more insight to the inner workings of Rails in relation to sql and could point out if these native sql-elements are available for/from a Rails-application it would be lovely if you could point at some Howto's, Tutorials.
Another thing I am wondering about is the use of foreign keys. Rails doesn't use them explicitly on the sql-side... would it be useful/helpful to manually add them to the database relations? Or would they hinder Rails' data access?
Thanks for any response, I am eager to find out what I can do between Rails and Sql to combine them in a maybe more efficient way.
As you will have noticed, and mention yourself: rails does a good job of hiding much of the sql/implementation details.
Still, I believe it is very important to use your sql and database wisely.
Validations
Validations should be defined on your database as much as possible, not only in rails. You define it in Rails to give nice user-feedback if needed. But ultimately you do not know how data gets into the database: some operator can use sql, maybe other programs interface with the database, or more frequent: two rails processes can insert data nearly simultaneously.
Foreign keys
Should most definitely be defined on your database. For rails is not needed, it will write the queries correctly, but this will guard your database against wrong data. This will safeguard your data integrity. If someones deletes a record and another record is still pointing to that, your database will complain.
Indexes
This is even more easily overlooked: create indexes! On your primary key (automatically), on much searched on fields (like name), on foreign key fields !!
Complicated queries
As much as rails helps you when retrieving items, for some queries it is much more efficient to write the query yourself. While I will avoid it as long as possible, find_by_sql is a powerful tool.
And rails is extremely powerful/helpful in treating the result of a find_by_sql as a normal result.
Stored procedures, functions, ...
Normally you do not need them when using rails. But there are some very valid cases where they are very useful. For instance, I have created a geographic information system, where we used stored procedures to create various spatial objects. In rails you can directly execute sql using the
YourModel.connection.execute(' .. your sql here .. ')
So even execute stored procedures. It will not be for everyone, but there are some very valid reasons to move work to the database. For example if you have to perform an operation over a whole lot of tables or rows, it could be very efficient to call a stored procedure instead of retrieving all the data, changing the rows, and saving them back. It depends on your problem at hand.
Conclusion
I want to make absolutely clear that Rails nicely abstracts the database away, and for everyday use this is just great. You should define foreign keys, indexes and constraints on your database. For the more advanced stuff like functions, stored procedures, complicated queries: Rails does not stop you from doing anything complicated if needed. One should consider your database as a tool as much as Rails is. But remember:
Premature optimization is the root of all evil. --Donald Knuth
So the options are available, but only use them if it is really necessary.
First of all, I don't particularly share your sentiments with regards to the following completely
Yes, from a developers view, sql is important, but somehow I didn't
need much of it... like stored procedures, functions, triggers, etc...
SQL is important if you're developing all the time for extreme "scalability" — and do note I'm using the term here very loosely as Rails does scale if you know how to go about it, but with limits as stories such as Twitter's switch from Rails etc. are quite ubiquitous.
However, Rails isn't always about extreme performance. It is first and foremost about developer 'happiness', increased productivity, and reduced time-to-market. This is done quite well, especially in Rails 3.x+ with the high abstraction introduced and it is this very abstraction that ultimately has resulted in Rails being considered as slow, and by most standards it definitely is.
Do note, that I do not intend to cause any 'language' flame-wars here but this is my personal take on the purpose of Rails; I like to call a duck a duck myself (much like two of my favourite languages: python & ruby).
The simple answer to your questions though can be realised as follows:
Triggers: AR callbacks
Functions: AR Query DSL, i.e. .where('name = ?', :full_name)
Stored Procedure: tied into model business logic, typically based on AR callback.
Another thing I am wondering about is the use of foreign keys. Rails
doesn't use them explicitly on the sql-side... would it be
useful/helpful to manually add them to the database relations?
Au contraire mon ami! All AR relations require that the various foreign keys are included in whatever appropriate migrations one includes. It's a common misconception that 'Rails will walk your dog and clean after it as well'. Remember that AR queries are ultimately expressed on your backend solution, in this case an SQL one for the sake of this topic, in SQL (alternatives are SQlite/PostgreSQL etc...).
However*, rails does not make use of FK constraints because you can actually make an _id field point to a non-existant record; they aren't really foreign keys in the strictest sense.
Note: the * indicates that credit for this statement should go to my friend David Workman (workmad3) and revision to the last paragraph of the above.