New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed #3214 -- Support batch custom sql loading (db-dependant) #1533

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@claudep
Member

claudep commented Aug 30, 2013

No description provided.

@mjtamlyn

This comment has been minimized.

Show comment
Hide comment
@mjtamlyn

mjtamlyn Aug 30, 2013

Member

With the migrations support, are .sql files even needed any more?

Member

mjtamlyn commented Aug 30, 2013

With the migrations support, are .sql files even needed any more?

@claudep

This comment has been minimized.

Show comment
Hide comment
@claudep

claudep Aug 30, 2013

Member

I've not yet played with the new migration support, so I can't judge. But does the migrations support the use case of, let's say, adding a specialized stored procedure?

Member

claudep commented Aug 30, 2013

I've not yet played with the new migration support, so I can't judge. But does the migrations support the use case of, let's say, adding a specialized stored procedure?

@claudep

This comment has been minimized.

Show comment
Hide comment
@claudep

claudep Aug 30, 2013

Member

Oh, and let's discuss the general issue on the ticket instead.

Member

claudep commented Aug 30, 2013

Oh, and let's discuss the general issue on the ticket instead.

@mjtamlyn

This comment has been minimized.

Show comment
Hide comment
@mjtamlyn

mjtamlyn Sep 16, 2013

Member

@andrewgodwin what's the status of .SQL files in a post migrations world?

Member

mjtamlyn commented Sep 16, 2013

@andrewgodwin what's the status of .SQL files in a post migrations world?

@andrewgodwin

This comment has been minimized.

Show comment
Hide comment
@andrewgodwin

andrewgodwin Sep 17, 2013

Member

@mjtamlyn They should go away, there's a RunSQL operation you can use in migrations instead (that accepts either single statements or mutiple ones with its own internal splitter regex). I didn't get around to removing the support for them on syncdb-type apps, but they'll be ignored if you have migrations.

Member

andrewgodwin commented Sep 17, 2013

@mjtamlyn They should go away, there's a RunSQL operation you can use in migrations instead (that accepts either single statements or mutiple ones with its own internal splitter regex). I didn't get around to removing the support for them on syncdb-type apps, but they'll be ignored if you have migrations.

@@ -212,6 +212,9 @@ def model_installed(model):
with transaction.commit_on_success_unless_managed(using=connection.alias):
for sql in custom_sql:
cursor.execute(sql)
if connection.vendor == 'mysql':
while cursor.nextset():
pass

This comment has been minimized.

@akaariai

akaariai Sep 25, 2013

Member

Usually non-test code doing connection.vendor checks should instead use some database feature flag or backend method. At least this needs an explanation why this is done.

@akaariai

akaariai Sep 25, 2013

Member

Usually non-test code doing connection.vendor checks should instead use some database feature flag or backend method. At least this needs an explanation why this is done.

Hook to let backends split some possibly multiline sql content if
they don't support multiple sql statements in one execute() call.
"""
return [sql]

This comment has been minimized.

@akaariai

akaariai Sep 25, 2013

Member

Should the default stay as split_statements()

@akaariai

akaariai Sep 25, 2013

Member

Should the default stay as split_statements()

# One global and one Postgres-specific
self.assertEqual(len(custom_sql), 2)
else:
self.assertEqual(len(custom_sql), 1)

This comment has been minimized.

@akaariai

akaariai Sep 25, 2013

Member

This will be called upon by third party db maintainers. I think it is OK to check each core DB here, and just no do any check for non-core databases at all.

@akaariai

akaariai Sep 25, 2013

Member

This will be called upon by third party db maintainers. I think it is OK to check each core DB here, and just no do any check for non-core databases at all.

cursor = connection.cursor()
for sql in custom_sql:
cursor.execute(sql)
if connection.vendor == 'mysql':
while cursor.nextset():
pass

This comment has been minimized.

@akaariai

akaariai Sep 25, 2013

Member

Here the same question, why this?

@akaariai

akaariai Sep 25, 2013

Member

Here the same question, why this?

@akaariai

This comment has been minimized.

Show comment
Hide comment
@akaariai

akaariai Sep 25, 2013

Member

Hmmh, reading andrew's comment after reviewing code changes... Should we just close this one?

Member

akaariai commented Sep 25, 2013

Hmmh, reading andrew's comment after reviewing code changes... Should we just close this one?

@claudep

This comment has been minimized.

Show comment
Hide comment
@claudep

claudep Sep 26, 2013

Member

Yes, we can close it. However, it should be used as a base (at least for testing) for an equivalent patch applied to the RunSQL method.

Member

claudep commented Sep 26, 2013

Yes, we can close it. However, it should be used as a base (at least for testing) for an equivalent patch applied to the RunSQL method.

@claudep claudep closed this Sep 26, 2013

@claudep claudep deleted the claudep:3214 branch Apr 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment