Databases
StackOverflow2013
Postsdbo
POTable created with Django has no content after view finishes
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POTable created with Django has no content after view finishes
    primarykey
    data
    text
    <p>I have a Django view that does some complex SQL queries and which contains code like the following:</p> <pre><code>sql1 = "CREATE TEMPORARY TABLE my_temp_table ..." cursor = connection.cursor() cursor.execute(sql1) ... sql2 = "INSERT INTO my_temp_table ..." cursor = connection.cursor() cursor.execute(sql2) </code></pre> <p>The queries are more complicated than this, but the idea should be clear: I create a temp table, then insert a bunch of stuff into it, which I use later on in the view. This works -- it is obvious, based on the view's performance, that the table is being created and the stuff is being inserted into it.</p> <p>However, in the course of adding a feature I wanted to inspect the results of what got inserted into <strong>my_temp_table</strong> in order to refine some of the queries that use it. So for exploratory purposes I changed the SQL to just create a regular table, so I could examine it afterward. So <em>sql1</em> became, in effect:</p> <pre><code>sql1 = "CREATE TABLE my_temp_table ..." cursor = connection.cursor() cursor.execute(sql1) </code></pre> <p>In other words, everything's the same except <strong>my_temp_table</strong> is created without the "TEMPORARY" modifier.</p> <p>The problem is that, when the query has finished, the <strong>my_temp_table</strong> table is empty -- none of the data that got inserted into it (in the <em>sql2</em> query) is actually in it after the view is finished. This is puzzling -- clearly the data was successfully inserted into <strong>my_test_table</strong> in the course of view execution, since otherwise the view wouldn't be able to do the stuff that it is clearly doing. But where did the data go?</p> <p>[One additional confirmation that the data actually <em>was</em> in the table at one point is the fact that I can log the query, then manually run the same query by hand, and everything works like I'd expect.]</p> <p>I'm running this with Django's testserver (via manage.py runserver) using Django 1.4.2.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USshanusmagnus
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COSounds like a transaction issue to me. Are you sure the transaction is committed at the end of the view?
      singulars
      1. POTable created with Django has no content after view finishes
      1. USDaniel Roseman
    2. COThat's what I thought, too, but nothing is changed from a transaction pov in changing from a temporary table to a non-temporary table [right?] unless there's some weird thing where you can write to a table, then read from a table, and then have the transaction not go through; although then you'd think the table wouldn't be created at all. Aside from that, Django dox claim default behavior is to have per-view transactions that commit unless an error occurs, and no error is occurring. Unless doing this SQL by hand changes that...
      singulars
      1. POTable created with Django has no content after view finishes
      1. USshanusmagnus
    3. COWell, in MySQL DDL commands are not considered part of a transaction, so it's perfectly understandable that the table gets created but the data is not visible. As for writing then reading it back, again that's what you'd expect if you were within a single transaction.
      singulars
      1. POTable created with Django has no content after view finishes
      1. USDaniel Roseman
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload