Removing unused SQLAlchemy Dialects and Tests?
up vote
0
down vote
favorite
I'm packaging SQLAlchemy, among other things, for deployment onto AWS Lambda and am looking to reduce the size of the zipped project archive. I see in sqlalchemy/dialects
that there are a list of dialects of SQL which SQLAlchemy supports:
48K ./firebird
48K ./sybase
88K ./sqlite
112K ./oracle
124K ./mssql
204K ./mysql
240K ./postgresql
Are there any issues with removing dialects for which this project is not using? If I'm only using MySQL, I surely wouldn't need an sqlite dialect definition.
Or perhaps removing the tests under sqlalchemy/testing
:
12K ./testing/engines.py
12K ./testing/fixtures.py
12K ./testing/profiling.py
16K ./testing/assertsql.py
16K ./testing/exclusions.py
16K ./testing/provision.py
20K ./testing/assertions.py
28K ./testing/requirements.py
36K ./testing/plugin
136K ./testing/suite
python sqlalchemy
add a comment |
up vote
0
down vote
favorite
I'm packaging SQLAlchemy, among other things, for deployment onto AWS Lambda and am looking to reduce the size of the zipped project archive. I see in sqlalchemy/dialects
that there are a list of dialects of SQL which SQLAlchemy supports:
48K ./firebird
48K ./sybase
88K ./sqlite
112K ./oracle
124K ./mssql
204K ./mysql
240K ./postgresql
Are there any issues with removing dialects for which this project is not using? If I'm only using MySQL, I surely wouldn't need an sqlite dialect definition.
Or perhaps removing the tests under sqlalchemy/testing
:
12K ./testing/engines.py
12K ./testing/fixtures.py
12K ./testing/profiling.py
16K ./testing/assertsql.py
16K ./testing/exclusions.py
16K ./testing/provision.py
20K ./testing/assertions.py
28K ./testing/requirements.py
36K ./testing/plugin
136K ./testing/suite
python sqlalchemy
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm packaging SQLAlchemy, among other things, for deployment onto AWS Lambda and am looking to reduce the size of the zipped project archive. I see in sqlalchemy/dialects
that there are a list of dialects of SQL which SQLAlchemy supports:
48K ./firebird
48K ./sybase
88K ./sqlite
112K ./oracle
124K ./mssql
204K ./mysql
240K ./postgresql
Are there any issues with removing dialects for which this project is not using? If I'm only using MySQL, I surely wouldn't need an sqlite dialect definition.
Or perhaps removing the tests under sqlalchemy/testing
:
12K ./testing/engines.py
12K ./testing/fixtures.py
12K ./testing/profiling.py
16K ./testing/assertsql.py
16K ./testing/exclusions.py
16K ./testing/provision.py
20K ./testing/assertions.py
28K ./testing/requirements.py
36K ./testing/plugin
136K ./testing/suite
python sqlalchemy
I'm packaging SQLAlchemy, among other things, for deployment onto AWS Lambda and am looking to reduce the size of the zipped project archive. I see in sqlalchemy/dialects
that there are a list of dialects of SQL which SQLAlchemy supports:
48K ./firebird
48K ./sybase
88K ./sqlite
112K ./oracle
124K ./mssql
204K ./mysql
240K ./postgresql
Are there any issues with removing dialects for which this project is not using? If I'm only using MySQL, I surely wouldn't need an sqlite dialect definition.
Or perhaps removing the tests under sqlalchemy/testing
:
12K ./testing/engines.py
12K ./testing/fixtures.py
12K ./testing/profiling.py
16K ./testing/assertsql.py
16K ./testing/exclusions.py
16K ./testing/provision.py
20K ./testing/assertions.py
28K ./testing/requirements.py
36K ./testing/plugin
136K ./testing/suite
python sqlalchemy
python sqlalchemy
edited Nov 11 at 1:31
asked Nov 11 at 1:26
Sean Pianka
855822
855822
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
I did a search for the word "dialects" in the SQLAlchemy github repo and the main module that stood out was SQLAlchemy.databases.__init__.py
:
from ..dialects.sqlite import base as sqlite
from ..dialects.postgresql import base as postgresql
postgres = postgresql
from ..dialects.mysql import base as mysql
from ..dialects.oracle import base as oracle
from ..dialects.firebird import base as firebird
from ..dialects.mssql import base as mssql
from ..dialects.sybase import base as sybase
__all__ = (
'firebird',
'mssql',
'mysql',
'postgresql',
'sqlite',
'oracle',
'sybase',
)
Which I changed to:
from ..dialects.mysql import base as mysql
__all__ = (
'mysql',
)
I also modified the __all__
declaration in sqlalchemy.dialects.__init__.py
. This:
__all__ = (
'firebird',
'mssql',
'mysql',
'oracle',
'postgresql',
'sqlite',
'sybase',
)
to:
__all__ = (
'mysql'
)
(I actually don't know if modifying those __all__
declarations is necessary. I didn't test it without doing it.)
I then deleted all of the sqlalchemy.dialects.*
sub directories except for mysql
and I was able to run few MySQL CRUD apps that I have sitting around without exception.
Also deleting the sqlalchemy.testing
folder didn't cause any problems.
I tried to run a sqllite app and got sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:sqlite
.
So it seems that with only having to modify one or two files, you can get away with it as long as only running on the dialect that you leave behind.
The main thing is that after removing the dialects, all of the tests for your application pass (assuming your test coverage is good) as I only tested on a pretty limited set of small ORM apps.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I did a search for the word "dialects" in the SQLAlchemy github repo and the main module that stood out was SQLAlchemy.databases.__init__.py
:
from ..dialects.sqlite import base as sqlite
from ..dialects.postgresql import base as postgresql
postgres = postgresql
from ..dialects.mysql import base as mysql
from ..dialects.oracle import base as oracle
from ..dialects.firebird import base as firebird
from ..dialects.mssql import base as mssql
from ..dialects.sybase import base as sybase
__all__ = (
'firebird',
'mssql',
'mysql',
'postgresql',
'sqlite',
'oracle',
'sybase',
)
Which I changed to:
from ..dialects.mysql import base as mysql
__all__ = (
'mysql',
)
I also modified the __all__
declaration in sqlalchemy.dialects.__init__.py
. This:
__all__ = (
'firebird',
'mssql',
'mysql',
'oracle',
'postgresql',
'sqlite',
'sybase',
)
to:
__all__ = (
'mysql'
)
(I actually don't know if modifying those __all__
declarations is necessary. I didn't test it without doing it.)
I then deleted all of the sqlalchemy.dialects.*
sub directories except for mysql
and I was able to run few MySQL CRUD apps that I have sitting around without exception.
Also deleting the sqlalchemy.testing
folder didn't cause any problems.
I tried to run a sqllite app and got sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:sqlite
.
So it seems that with only having to modify one or two files, you can get away with it as long as only running on the dialect that you leave behind.
The main thing is that after removing the dialects, all of the tests for your application pass (assuming your test coverage is good) as I only tested on a pretty limited set of small ORM apps.
add a comment |
up vote
1
down vote
accepted
I did a search for the word "dialects" in the SQLAlchemy github repo and the main module that stood out was SQLAlchemy.databases.__init__.py
:
from ..dialects.sqlite import base as sqlite
from ..dialects.postgresql import base as postgresql
postgres = postgresql
from ..dialects.mysql import base as mysql
from ..dialects.oracle import base as oracle
from ..dialects.firebird import base as firebird
from ..dialects.mssql import base as mssql
from ..dialects.sybase import base as sybase
__all__ = (
'firebird',
'mssql',
'mysql',
'postgresql',
'sqlite',
'oracle',
'sybase',
)
Which I changed to:
from ..dialects.mysql import base as mysql
__all__ = (
'mysql',
)
I also modified the __all__
declaration in sqlalchemy.dialects.__init__.py
. This:
__all__ = (
'firebird',
'mssql',
'mysql',
'oracle',
'postgresql',
'sqlite',
'sybase',
)
to:
__all__ = (
'mysql'
)
(I actually don't know if modifying those __all__
declarations is necessary. I didn't test it without doing it.)
I then deleted all of the sqlalchemy.dialects.*
sub directories except for mysql
and I was able to run few MySQL CRUD apps that I have sitting around without exception.
Also deleting the sqlalchemy.testing
folder didn't cause any problems.
I tried to run a sqllite app and got sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:sqlite
.
So it seems that with only having to modify one or two files, you can get away with it as long as only running on the dialect that you leave behind.
The main thing is that after removing the dialects, all of the tests for your application pass (assuming your test coverage is good) as I only tested on a pretty limited set of small ORM apps.
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I did a search for the word "dialects" in the SQLAlchemy github repo and the main module that stood out was SQLAlchemy.databases.__init__.py
:
from ..dialects.sqlite import base as sqlite
from ..dialects.postgresql import base as postgresql
postgres = postgresql
from ..dialects.mysql import base as mysql
from ..dialects.oracle import base as oracle
from ..dialects.firebird import base as firebird
from ..dialects.mssql import base as mssql
from ..dialects.sybase import base as sybase
__all__ = (
'firebird',
'mssql',
'mysql',
'postgresql',
'sqlite',
'oracle',
'sybase',
)
Which I changed to:
from ..dialects.mysql import base as mysql
__all__ = (
'mysql',
)
I also modified the __all__
declaration in sqlalchemy.dialects.__init__.py
. This:
__all__ = (
'firebird',
'mssql',
'mysql',
'oracle',
'postgresql',
'sqlite',
'sybase',
)
to:
__all__ = (
'mysql'
)
(I actually don't know if modifying those __all__
declarations is necessary. I didn't test it without doing it.)
I then deleted all of the sqlalchemy.dialects.*
sub directories except for mysql
and I was able to run few MySQL CRUD apps that I have sitting around without exception.
Also deleting the sqlalchemy.testing
folder didn't cause any problems.
I tried to run a sqllite app and got sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:sqlite
.
So it seems that with only having to modify one or two files, you can get away with it as long as only running on the dialect that you leave behind.
The main thing is that after removing the dialects, all of the tests for your application pass (assuming your test coverage is good) as I only tested on a pretty limited set of small ORM apps.
I did a search for the word "dialects" in the SQLAlchemy github repo and the main module that stood out was SQLAlchemy.databases.__init__.py
:
from ..dialects.sqlite import base as sqlite
from ..dialects.postgresql import base as postgresql
postgres = postgresql
from ..dialects.mysql import base as mysql
from ..dialects.oracle import base as oracle
from ..dialects.firebird import base as firebird
from ..dialects.mssql import base as mssql
from ..dialects.sybase import base as sybase
__all__ = (
'firebird',
'mssql',
'mysql',
'postgresql',
'sqlite',
'oracle',
'sybase',
)
Which I changed to:
from ..dialects.mysql import base as mysql
__all__ = (
'mysql',
)
I also modified the __all__
declaration in sqlalchemy.dialects.__init__.py
. This:
__all__ = (
'firebird',
'mssql',
'mysql',
'oracle',
'postgresql',
'sqlite',
'sybase',
)
to:
__all__ = (
'mysql'
)
(I actually don't know if modifying those __all__
declarations is necessary. I didn't test it without doing it.)
I then deleted all of the sqlalchemy.dialects.*
sub directories except for mysql
and I was able to run few MySQL CRUD apps that I have sitting around without exception.
Also deleting the sqlalchemy.testing
folder didn't cause any problems.
I tried to run a sqllite app and got sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:sqlite
.
So it seems that with only having to modify one or two files, you can get away with it as long as only running on the dialect that you leave behind.
The main thing is that after removing the dialects, all of the tests for your application pass (assuming your test coverage is good) as I only tested on a pretty limited set of small ORM apps.
answered Nov 11 at 8:30
SuperShoot
1,448619
1,448619
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53245059%2fremoving-unused-sqlalchemy-dialects-and-tests%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown