Re: [sqlalchemy] Any recommended approach for creating a new dialect?
Hi Michael, thanks for the prompt response and your directions. This was really helpful. I will start as you've described in your reply. Ralph On Wednesday, April 8, 2015 at 6:19:27 AM UTC+2, Michael Bayer wrote: On 4/7/15 1:59 PM, Ralph Heinkel wrote: Hello dialect experts, what would be the best approach for creating a SqlAlchemy dialect for a new database system? Are there any recipes available for this area, or is the way to go to read code of existing dialects and derive my own dialect from those? I had a first glance at some built-in dialects, and also some in external packages ... it is not always obvious to me why certain classes and methods have been implemented. The obvious thing is to create a subclass of sqlalchemy.enginedefault.DefaultDialect, but how would I know which methods and class attributes to override/implement, except for going through the trial and error approach? And then there are other classes which are implemented in some dialects, like compiler.DDLCompiler, compiler.GenericTypeCompiler, and so on ... where and how would I start best? Any help would be very much appreciated. Start with the README for new dialects: https://bitbucket.org/zzzeek/sqlalchemy/src/44a9820b4e02f65b3884fa2c016efce9663e4910/README.dialects.rst?at=master that will show the guidelines for writing new dialects. Then to see some examples of that layout, take a look at some of the 3rd party dialects listed at: http://docs.sqlalchemy.org/en/latest/dialects/index.html#production-ready Also the sqlalchemy-access dialect is basically something of a demo for the layout, which I basically put there after extracting it from SQLAlchemy main where it had been for many years. It might not be 100% up to date, but mostly follows that guideline and even passed tests at one point, that's at https://bitbucket.org/zzzeek/sqlalchemy-access. The key thing you'll be doing is running the suite tests, which will be part of the test suite within your own dialect. So yes, you start with a fairly plain subclass of DefaultDialect, then you probably want to get a hello world kind of program going where you just see if create_engine and then engine.execute(select * from table) work at all, and then the suite tests should test a lot more. Ciao ciao Ralph -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Any recommended approach for creating a new dialect?
Mike, I remember an article of yours where you described much of the process of creating a new dialect for SA, for a Java database if I'm not mistaken. I wasn't able to find it, though. :) On 04/08/2015 01:19 AM, Mike Bayer wrote: On 4/7/15 1:59 PM, Ralph Heinkel wrote: Hello dialect experts, what would be the best approach for creating a SqlAlchemy dialect for a new database system? Are there any recipes available for this area, or is the way to go to read code of existing dialects and derive my own dialect from those? I had a first glance at some built-in dialects, and also some in external packages ... it is not always obvious to me why certain classes and methods have been implemented. The obvious thing is to create a subclass of sqlalchemy.enginedefault.DefaultDialect, but how would I know which methods and class attributes to override/implement, except for going through the trial and error approach? And then there are other classes which are implemented in some dialects, like compiler.DDLCompiler, compiler.GenericTypeCompiler, and so on ... where and how would I start best? Any help would be very much appreciated. Start with the README for new dialects: https://bitbucket.org/zzzeek/sqlalchemy/src/44a9820b4e02f65b3884fa2c016efce9663e4910/README.dialects.rst?at=master that will show the guidelines for writing new dialects. Then to see some examples of that layout, take a look at some of the 3rd party dialects listed at: http://docs.sqlalchemy.org/en/latest/dialects/index.html#production-ready Also the sqlalchemy-access dialect is basically something of a demo for the layout, which I basically put there after extracting it from SQLAlchemy main where it had been for many years. It might not be 100% up to date, but mostly follows that guideline and even passed tests at one point, that's at https://bitbucket.org/zzzeek/sqlalchemy-access. The key thing you'll be doing is running the suite tests, which will be part of the test suite within your own dialect. So yes, you start with a fairly plain subclass of DefaultDialect, then you probably want to get a hello world kind of program going where you just see if create_engine and then engine.execute(select * from table) work at all, and then the suite tests should test a lot more. Ciao ciao Ralph -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com mailto:sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com mailto:sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com mailto:sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com mailto:sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Any recommended approach for creating a new dialect?
Hello dialect experts, what would be the best approach for creating a SqlAlchemy dialect for a new database system? Are there any recipes available for this area, or is the way to go to read code of existing dialects and derive my own dialect from those? I had a first glance at some built-in dialects, and also some in external packages ... it is not always obvious to me why certain classes and methods have been implemented. The obvious thing is to create a subclass of sqlalchemy.enginedefault.DefaultDialect, but how would I know which methods and class attributes to override/implement, except for going through the trial and error approach? And then there are other classes which are implemented in some dialects, like compiler.DDLCompiler, compiler.GenericTypeCompiler, and so on ... where and how would I start best? Any help would be very much appreciated. Ciao ciao Ralph -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Any recommended approach for creating a new dialect?
On 4/7/15 1:59 PM, Ralph Heinkel wrote: Hello dialect experts, what would be the best approach for creating a SqlAlchemy dialect for a new database system? Are there any recipes available for this area, or is the way to go to read code of existing dialects and derive my own dialect from those? I had a first glance at some built-in dialects, and also some in external packages ... it is not always obvious to me why certain classes and methods have been implemented. The obvious thing is to create a subclass of sqlalchemy.enginedefault.DefaultDialect, but how would I know which methods and class attributes to override/implement, except for going through the trial and error approach? And then there are other classes which are implemented in some dialects, like compiler.DDLCompiler, compiler.GenericTypeCompiler, and so on ... where and how would I start best? Any help would be very much appreciated. Start with the README for new dialects: https://bitbucket.org/zzzeek/sqlalchemy/src/44a9820b4e02f65b3884fa2c016efce9663e4910/README.dialects.rst?at=master that will show the guidelines for writing new dialects. Then to see some examples of that layout, take a look at some of the 3rd party dialects listed at: http://docs.sqlalchemy.org/en/latest/dialects/index.html#production-ready Also the sqlalchemy-access dialect is basically something of a demo for the layout, which I basically put there after extracting it from SQLAlchemy main where it had been for many years. It might not be 100% up to date, but mostly follows that guideline and even passed tests at one point, that's at https://bitbucket.org/zzzeek/sqlalchemy-access. The key thing you'll be doing is running the suite tests, which will be part of the test suite within your own dialect. So yes, you start with a fairly plain subclass of DefaultDialect, then you probably want to get a hello world kind of program going where you just see if create_engine and then engine.execute(select * from table) work at all, and then the suite tests should test a lot more. Ciao ciao Ralph -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com mailto:sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com mailto:sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
