Determine/Find underlying SQL field type of a Django Field - sql

Is there an easy way to determine or find the underlying SQL field type of a Django Field, for any of the supported by default database backends? I have searched on the web and there is no documentation over how the Django fields are represented in SQL in each of the supported databases. The only way for me to see the underlying SQL field type, is to run the mysqlmigrate command of manage.py and examine the SQL code.

The type depends on the database backend, so you need to get a db connection first:
from django.db import connection
and now you can look up the field via the model Meta API:
my_field = MyModel._meta.get_field('my_field_name')
and use its db_type method:
my_field.db_type(connection)
which will return something like "varchar(10)".
Be sure you really need to do this, though. Usually this information is only useful inside migrations.

Related

rename database field in upgrade wizard of an extension in TYPO3 11

I have an upgrade wizard (TYPO3 11) which changes the data of a table.
This is done with the querybuilder:
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('tt_content');
$queryBuilder
->update('tt_content')
->set('CType', 'newCType')
->where($queryBuilder
->expr()
->eq('CType',$queryBuilder->createNamedParameter('oldCType')))
->execute();
But I also need to rename a field in a table:
ALTER TABLE tt_content RENAME COLUMN tx_myext_old_field TO tx_myext_new_field;
I can't find any documentation or example of doing this with the querybuilder.
The normal way woult be to provide a ext_tables.sql in your extension. This is read by TYPO3 to build a virtual "database scheme" how it should look.
The database schema analyser will than provide the information, and database alteration are suggested.
You could add a database must be up to date constraint to your upgrade wizard, that way it is ensured that the field is changed.
DTL is a special task, and you have to provide the correspinng queries yourself ... which are different for different dbms systems. So using the normal way would be recommended.
The platform/driver may have some generig helper methods providing some native sql parts for doing stuffs like that. The may be possible to provide custom stuff based on SchemaMigrator or SchemaManger etc - but thats low-level stuff.
doctrine/dbal directly do not really provide these DTL as API. And the querybuilder is not meant to be used for that low level stuff at all. That's the wrong tool for such tasks.
You can also change columns of core tables that way, by providing simply the table name and the column defintion only for the field you want to change.
The official way is to handle this with ext_tables.sql and the database schema analyser.
See: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/FileStructure/ExtTablesSql.html
The concept of renaming a column could not work:
On installing the extension all new fields are generated (or should be generated if in composer mode). And as the extension should work with the new columns they are already defined.
And before the upgrade wizard could rename a column these columns are existent already which prevents a rename.
In the end I do a content copy enhancing the update query like this:
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('tt_content');
$queryBuilder
->update('tt_content')
->set('CType', 'newCType')
->set('tx_myext_newfield1',$queryBuilder->quoteIdentifier('tx_myext_oldfield1'),false)
->set('tx_myext_newfield2',$queryBuilder->quoteIdentifier('tx_myext_oldfield2'),false)
->where($queryBuilder
->expr()
->eq('CType',$queryBuilder->createNamedParameter('oldCType')))
->executeStatement();

Django: how to view raw sql response upon a query

In Django if I want to see the raw sql in debug mode I can check using in django shell:
from django.db import connections
User.objects.all()
print(connections['default'].queries[-1]['sql'])
Similarly can we see the raw response of that sql. In the above case the sql query may return the raw results in csv, tab delimited format. From then django may create the model objects array.
There are better tools to debug SQL queries in Django. The standard tool is to use Django-debug-toolbar, which allows you to view both the SQL query, the result, and the EXPLAIN output, for all queries in a request/response, along with the time needed for each query. The documentation is available at https://django-debug-toolbar.readthedocs.io/en/latest/
you can do:
str(User.objects.all().query)
# or
print(User.objects.all().query)
# or
print(User.objects.all().query.sql_with_params())

How can I use prefix tables in database like am_user with ra-data-opencrud

library : https://github.com/Weakky/ra-data-opencrud/
I've been struggling since 5 days and not able to fixed. I'm using prisma with mysql
if tables in database was like this User, Post . it will work fine
the issue is all tables are named like this am_user , am_post
in this library they used this
${pluralize(camelCase(resource.name))};
who is the hero who can save me? i'm not able to find any workaround
I am not familiar with Prisma but this question is labelled react-admin... do you have no control over your schema type definitions, react admin would only care how your schema is named i am thinking not your db tables... and there must be a way to alias the Post to target ma_post for prisma .. I had to do the same thing but i used sequelize and the functionality for aliasing is quite simple
It sounds to me like you didn't create your database and are attempting to use it with an existing database? I tried this and could not get Prisma to run, that functionality was experimental when i tried it, and i believe it still is and the introspection works for postgres only... however something like this is what i was talking about from a quick google search of prisma docs (This is for postgres)
type Bill #pgTable(name: "ma_bill") {
bill: String!
id: Int! #unique
bill_products: [Bill_product]
}
This link seems to say introspection is possible for mysql tho, check it out
https://www.npmjs.com/package/prisma-db-introspection

TypeScript generation for SQL files

I'm interested to know if anyone has come across a tool that can generate TypeScript type definitions based on the expected result of a SQL query? That is to say, is there a CLI that accepts a SQL schema and .sql file and outputs a .ts file based on the expected result of the query?
Such a tool already exists for GraphQL queries and my team has found it extremely useful because it completely removes errors associated with hand-rolled type definitions.
Yes, PgTyped is a new tool that does that.
It allows you to generate TypeScript interfaces for raw SQL queries.
It works similarly to apollo-codegen, but instead of the gql tag you need to use a sql tag for your SQL queries.
It only supports PostgreSQL and is still in beta stage, but I am actively working on it and any contributions are welcome.
sql-code-generator is another option.
It does:
generating type definitions from SQL resources (e.g., tables, views, functions, procedures)
generating type definitions from SQL queries (e.g., select * from table)
generating typed functions that execute SQL queries from SQL queries (e.g., const sqlQueryFindAllUsersByName = async ({ input: InputType }): Promise)

SQL statement against Access 2010 DB not working with ODBC

I'm attempting to run a simple statement against an Access DB to find records.
Data validation in the records was horrible, and I cannot sanitize it. Meaning, it must be preserved as is.
I need to be able to search against a string with white space and hyphen characters removed. The following statement will work in Access 2010 direct:
select * from dummy where Replace(Replace([data1],' ',''),'-','') = 'ABCD1234';
Running it from an ODBC connection via PHP will not. It produces the following error:
SQL error: [Microsoft][ODBC Microsoft Access Driver] Undefined function 'Replace' in expression., SQL state 37000 in SQLExecDirect
Creating a query in the database that runs the function and attempting to search its values indirectly causes the same error:
select * from dummy_indirect where Expr1 = 'ABCD1234';
I've attempted to use both ODBC drivers present. ODBCJR32.dll (03/22/2010) and ACEODBC.dll (02/18/2007). To my knowledge these should be current as it was installed with the full Access 2010 and Access 2010 Database Engine.
Any ideas on how to work around this error and achieve the same effect are welcome. Please note, that I cannot alter the database in way, shape, or form. That indirect query was created in another mdb file that has the original tables linked from the original DB.
* Update *
OleDB did not really affect anything.
$dsn= "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\dummy.mdb;";
I'm not attempting to use it as a web backend either. I'm not a sadomasochist.
There is a legacy system that I must support that does use Access as a backend. Data gets populated there from other old systems that I must integrate into more modern systems. Hence, the creation of an API with Apache/PHP that is running on the server supporting the legacy system.
I need to be able to search a table that has an alphanumeric case identifier to get a numeric identifier that is unique and tied to a generator (Autonumber in access). Users have been using it a trash box for years (inconsistent data entry with sporadic notations) so the only solution I have is to strip everything except alphanumeric out of both the field value and the search value and attempt to perform a LIKE comparison against it.
If not replace() which is access supported, what ODBC compatible functions exist that I can use do the same kind of comparison?
Just to recap, the Access db engine will not recognize the Replace() function unless your query is run from within an Access application session. Any attempt from outside Access will trigger that "Undefined function" error message. You can't avoid the error by switching from ODBC to OleDb as the connection method. And you also can't trick the engine into using Replace() by hiding it in separate query (in the same or another Access db) and using that query as the data source for your main query.
This behavior is determined by Access' sandbox mode. That linked page includes a list of functions which are available in the default sandbox mode. That page also describes how you can alter the sandbox mode. If you absolutely must have Replace() available for your query, perhaps the lowest setting (0) would allow it. However, I'm not recommending you do that. I've never done it myself, so don't know anything about the consequences.
As for alternatives for Replace(), it would help to know about the variability in the values you're searching. If the space or dash characters appear in only one or a few consistent positions, you could do a pattern match with a Like expression. For example, if the search field values consist of 4 letters, an optional space or dash, followed by 4 digits, a WHERE clause like this should work for the variations of "ABCD1234":
SELECT * FROM dummy
WHERE
data1 = 'ABCD1234'
OR data1 Like 'ABCD[- ]1234';
Another possibility is to compare against a list of values:
SELECT * FROM dummy
WHERE
data1 IN ('ABCD1234','ABCD 1234','ABCD-1234');
However if your search field values can include any number of spaces or dashes at any position within the string, that approach is no good. And I would look real hard for some way to make the query task easier:
You can't clean the stored values because you're prohibited from altering the original Access db in any way. Perhaps you could create a new Access db, import the data, and clean that instead.
Set up the original Access db as a linked server in SQL Server and build your query to take advantage of SQL Server features.
Surrender. :-( Pull in a larger data set to your PHP client code, and evaluate which rows to use vs. which to ignore.
I'm not sure you can do this with ODBC and your constraints. The MS Access driver is limited (by design; MS wants you to use SQL Server for back ends).
Can you use OLEDB? that might be an option.