I am locking for a read-write lock in Django, using PostgreSQL.
I know select_for_update
On top, I need SELECT FOR SHARE
I founds this super old Django-ticket
I couldn't find any third party library implementing this for Django
Now I am wondering:
Is there a good reason this was not implemented in the Django-ORM?
Does anyone know any third party library for this?
Or any easy work around?
Can't you wrap the logic in pl/pgsql function that uses select for share and you then call the function from django?
Is there a good reason this was not implemented in the Django-ORM?
The ticket you've posted probably provides the reason: no one is motivated enough to write a patch.
Does anyone know any third party library for this?
Not me, sorry.
And if by any chance you are thinking about ditching Django for some other ORM then you must ask yourself: "There is a feature I need that's missing in Django... what features will I miss in this other ORM?"
Or any easy work around?
Probably not. But here are some options:
Every ORM I know has an escape hatch to raw SQL. You probably know that, but reluctant to use it... But, as you also lack the motivation to make a pull request, that probably means that you do not have hundreds of requests that require SELECT FOR SHARE functionality. So you should consider it. Performing raw SQL queries
Stored procedures as steve mentioned
https://docs.djangoproject.com/en/3.0/topics/db/sql/#calling-stored-procedures
The last comment on the ticked you've posted is from a man (David Schwärzle) who claims that he has a solution (not for PostgreSQL specifically but a solution nevertheless)... maybe you should try and contact him.
Haven't tried it, but probably the way you can add the desired functionality is by Writing your own Query Expressions
You can easily implement with a raw query.
from django.db import connection
query = f"""SELECT * FROM "appname_modelname" WHERE id={obj_id} FOR SHARE"""
with connection.cursor() as cursor:
cursor.execute(query, None)
obj_id is python variable.
appname_modelname is name of table created in your db by django. Django by default combines lowercased app name and model name with underscore.
Yugabyte seems to support Redis, Cassandra and SQL queries. Do they work with each other? For example, can I write data with Cassandra API and later perform SQL queries against them?
These APIs do not work with each other as is, meaning you would not be able to query YCQL data from YSQL. This is because the data types are all not always present in the other APIs, and they often have different semantics.
That said, we get asked this a lot and the plan is to enable this scenario using a foreign data wrapper. So, in effect, you would be able to "import" the YCQL table into the YSQL side and use it there. Note that PostgreSQL already has a bunch of these wrappers (for example, see this generic list of PG FDWs here - it has entries for Cassandra and Redis). The idea is to re-use/enhance these and get them to work out of the box.
If you're interested, please open a GitHub issue and we can continue there. Would love to understand your use-case better to make sure we are able to address it and work with you closely on this.
I'm learning about SQL databases so that I can work on an existing database, and I noticed this naming convention used on a lot of the files.
I'm thinking usp stands for User Stored Procedures, but I'm not entirely certain what parmsel is for. I've tried looking this up and see others using it with the case parmSel...
So what does usp_parmsel stand for?
The files are named like so under Programmability > Stored Procedures in the SQL Object Explorer:
dbo.usp_parmsel_CustomerExists
dbo.usp_parmsel_CustomerReferral
dbo.usp_parmsel_CustomerReceipt
Thanks!
Parmsel stands for parameter selector. You can look up parameter selectors on an engine search machine.
Apparently The PARMSEL field determines the format of the remainder of the area.
There is very vague information about it online.
Maybe this? https://documentation.devexpress.com/#CodeRush/CustomDocument1524
I was finally able to verify 100% with a higher up-- it stands for Parameter Select.
I saw a few places online where this was used, it looks like a rather old naming convention-- which makes sense, I'm working with an old system.
I am a developer for a global application, which was deployed in a few countries whose languages were not a problem for us. But now, we're going to Slovakia, and we're having a bit of trouble with EclipseLink.
We've setup a small web application to test the text encoding on the database for their project. We're able to read data using EclipseLink, which was inserted directly on the database (SQL server), but when trying to insert using the EntityManager, EclipseLink sends a bunch of unicode chars instead, which are not 'translated' by the database, but inserted as is.
I'm kinda clueless so far, since I've tried to search on EclipseLink for documentation regarding this topic, but had no luck. Can you guys share some of your wisdom regarding this? Anyone had to support other languages using ORM frameworks, and can share their experience?
Thanks in advance!
As it turns out, the issue is dealt with at the DBMS level. The tables that contain textual data need an appropriate type in order to handle unicode characters; in the case of SQL server, this type is 'nvarchar'.
We have a Delphi 2006 application that drives a MS SQL Server database.
We have found a vulnerability where it is possible to load the executable into a hex editor and modify the SQL.
Our long term plan is to move this SQL to CLR stored procedures but this is some way off since many of our clients still use SQL 2000.
We've thought about obfuscating the strings, does anyone have a recommendation for a tool for doing this?
Is there a better solution, maybe code signing?
Sorry for being blunt, but if you are thinking of applying "security" measures in your executable you are doomed. No scrambling schema will retain an average hacker.
You also haven't explained how is your app designed. Is the database hosted by you, or resides in your client's premises? If the latter, then just forget about security and start hiring a lawyer to get a good confidentiality contract so your clients behave. If the former, then using stored procedures is the easiest way.
If embedded SQL is being hacked, then it implies that your database is quite open and anyone with MSQRY32.EXE (that is, MS Office) can get your data.
If you are a vendor, then you can't rely on CLR being enabled at your clients. So, why not use non-CLR stored procedures and correct permissioning in the database that is version independent?
This is not a vulnerability. If your machines are vulnerable to having people locally modify EXEs, that is your vulnerability.
All EXEs can be hacked, if someone has local admin account access, your game is over long before they get near your resource strings.
It will never be possible to protect completely, but you can make "casual attack" harder. The simple system that I use is a "ROT47" type system which is like ROT13 but wider ranging. The code then gets to look like the following:
frmLogin.Caption := xIniFile.ReadString(Rot47('$JDE6>' {CODEME'System'}),
The key here is that I have a comment which includes the string so both I can see it, but more importantly so can the utility that I run in my FinalBuilder build script. This allows me to ensure that strings are up-to-date at all times in release code. The utility looks for {CODEME in the lines, and if found knows the format of the data to output appropriately.
A solution that would require a deep restructuring of the application would be to use a multi-tier approach - most the of the SQL code would be in the application server module, that being on a server should be more protected than a client side exe.
Can't you encrypt all your queries and put them to the resource file?
During runtime, firstly you would have to:
Load your query string from resource.
Decrypt it.
Then you just run your query as before.
That should not be a big problem. Of course if you are not storing your queries in some resource / folder than you need to refactor your application a bit. But you should store them anyway in some organized manner. So you will be hitting a two birds with one stone here ;-)
For encryption of the strings you could use a free library called DCPCrypt.
I think you should use a exe packer which makes it hard for anyone to modify the stuff using hex editor.
First - do an analysis of your threat. Who is using your vulnerability, why is this a problem. Then act accordingly.
If your application is win32 and your threat are some kids witch are just having fun, a free exe packer (e.g. upx) might be the solution. On .NET applications signing might be what you want.
If you need more than that, it's going to be expensive and it's going to be more difficult to develop your application. Perhaps you even need to restructure it. Commercial protection schemes are available (perhaps with dongle?) - even protection schemes where you store your strings on some external hardware. If the hardware is not present, no SQL-Strings. But, as I said, that's more expensive.
Move DB interface to stored procedures. Normal regular stored procedures without any CLR. It's not a big deal if you already have queries to put inside.
If you don't want to learn T-SQL for some reasons, simple move all you query string to database and store in application single query, which purpose is reading SQL code with given query ID from database only.
All tricks with encoding produces a lot of troubles, but don't give any real security because must use reversable encrypting (dictated by the nature of the problem) and all keys for decoding placed in application executable too.
There are "protection" suites that encrypt and/or validate your exe before running. searching for "encrypt exe" or "validate exe" or so will probably help. Usually they are payware, but sub $100.
The principle is the same as an exe packer (and has some of its downsides, like cheaper antivirus heuristics sometimes reacting on them, a slightly elevated memory load), just more focussed on security. A problem is also that for most exe packers, depackers exist.
I use dinkeydongle's wares, but that is a kind that also ties into an hardware dongle, so that might be a bridge to far for you.