Skip to content
This repository was archived by the owner on Feb 27, 2020. It is now read-only.

MySQL Compatibility#2

Open
chawco wants to merge 2 commits into2degrees:masterfrom
chawco:feature/mysql-compatability
Open

MySQL Compatibility#2
chawco wants to merge 2 commits into2degrees:masterfrom
chawco:feature/mysql-compatability

Conversation

@chawco
Copy link

@chawco chawco commented Mar 4, 2011

It looks like the current field definition in Djeneralize isn't compatible with MySQL -- the TextField maps to a BLOB, which isn't indexable on MySQL. This is a change to switch the field to a CharField of the max indexable length as described here:

http://docs.djangoproject.com/en/dev/ref/databases/

chawco added 2 commits March 4, 2011 11:15
BLOBS, which cannot be indexed, while CharFields can be. We specify
the largest reasonable length as suggested by Django here:

http://docs.djangoproject.com/en/dev/ref/databases/
@euangoddard
Copy link

Thanks for the feedback. My apologies for the slow reply. I've been snowed under at work trying to finish a project for which djeneralize is used.

I opted for TextField as some reading suggested that indexing a TEXT field in Postgres is more efficient than a VARCHAR. Also, as you point out the size of the field is unlimited (although 255 chars should be plenty for most purposes).

When I've finished this project I'll take a look at your changes.

Thanks for the input, Euan

@chawco
Copy link
Author

chawco commented Mar 16, 2011

Thanks for the reply. There's another alternative here -- which is to not place an index on this column. I'm not sure under what situations this index would be used. If the index is removed the resulting TEXT field should work just fine.

@chawco
Copy link
Author

chawco commented May 26, 2011

Have you gotten a chance to review this? We're still deploying a patched version of this package, and it would be nice to be able to use the version on the public PyPI instead of our custom distribution.

@euangoddard
Copy link

Apologies for not replying to this. I have been thinking about it. Unfortunately the changed you suggest would actually impact on the performance of our system (since it uses postgres). I can't think of a solution which solves both problems without having something like a custom backend specific version, but that seems a bit horrible.

Let me have a chat to my colleagues and see if they have any suggestions.

Thanks, Euan

@euangoddard
Copy link

I have spoken with a colleague of mine and he is of the opinion that providing we don't see a significant performance degradation we should accept your changes. However, we would need to validate this by running a benchmark. If you could provide a mechanism for running this benchmark, we can create two virtualenvs on our servers - one with each code set and test the performance difference.

Thanks, Euan

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants