[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 7, 2008 2:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: 0.4.2b -- - sql - changed name of TEXT to Text since its a generic type; TEXT name is deprecated until 0.5. The upgrading behavior of String to Text when no length is present is also deprecated until 0.5; will issue a warning when used for CREATE TABLE statements (String with no length for SQL expression purposes is still fine) [ticket:912] What are we supposed to do with Unicode? As far as I can tell, the Unicode type passes its defined length directly to the underlying string, so that a Unicode(30) column is turned into a VARCHAR(30) or the dialect equivalent. I may be able to determine that a particular column should hold up to 30 Unicode characters, for example, but if the default encoding of UTF-8 is used, each character will use anywhere from one to four byes, so that in the extreme case, it will be trying to stuff a 120-byte string into a VARCHAR(30)! The only way to be certain of the length is to use UTF-32, although in practice I doubt I will ever get astral plane characters in this app, so UTF-16 would probably be sufficient. But I _like_ UTF-8 and would prefer to use it. Perhaps the Unicode type should multiply its length by 4? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
Jon Rosebaugh wrote: What are we supposed to do with Unicode? As far as I can tell, the Unicode type passes its defined length directly to the underlying string, so that a Unicode(30) column is turned into a VARCHAR(30) or the dialect equivalent. I may be able to determine that a particular column should hold up to 30 Unicode characters, for example, but if the default encoding of UTF-8 is used, each character will use anywhere from one to four byes, so that in the extreme case, it will be trying to stuff a 120-byte string into a VARCHAR(30)! The only way to be certain of the length is to use UTF-32, although in practice I doubt I will ever get astral plane characters in this app, so UTF-16 would probably be sufficient. But I _like_ UTF-8 and would prefer to use it. Perhaps the Unicode type should multiply its length by 4? What RDBMS you use? And what is the encoding of the specific database where you tested this? If you have a database with UTF-8 encoding then it will be expecting 30 Unicode characters coded with the UTF-8 encoding, no matter how many bytes it takes to store then. A VARCHAR(30) is not referring to 30 bytes, but to 30 characters. If you are mixing encodings then sooner or later you'll have big problems. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
Jorge Godoy schrieb: Jon Rosebaugh wrote: What are we supposed to do with Unicode? As far as I can tell, the Unicode type passes its defined length directly to the underlying string, so that a Unicode(30) column is turned into a VARCHAR(30) or the dialect equivalent. I may be able to determine that a particular column should hold up to 30 Unicode characters, for example, but if the default encoding of UTF-8 is used, each character will use anywhere from one to four byes, so that in the extreme case, it will be trying to stuff a 120-byte string into a VARCHAR(30)! The only way to be certain of the length is to use UTF-32, although in practice I doubt I will ever get astral plane characters in this app, so UTF-16 would probably be sufficient. But I _like_ UTF-8 and would prefer to use it. Perhaps the Unicode type should multiply its length by 4? What RDBMS you use? And what is the encoding of the specific database where you tested this? If you have a database with UTF-8 encoding then it will be expecting 30 Unicode characters coded with the UTF-8 encoding, no matter how many bytes it takes to store then. A VARCHAR(30) is not referring to 30 bytes, but to 30 characters. Unless he is using Oracle with NLS_LENGTH_SEMANTICS as Bytes..., then its really Bytes..., but thats a bad setting for various reasons. Michael -- Michael Schlenker Software Engineer CONTACT Software GmbH Tel.: +49 (421) 20153-80 Wiener Straße 1-3 Fax:+49 (421) 20153-41 28359 Bremen http://www.contact.de/ E-Mail: [EMAIL PROTECTED] Sitz der Gesellschaft: Bremen | Geschäftsführer: Karl Heinz Zachries Eingetragen im Handelsregister des Amtsgerichts Bremen unter HRB 13215 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 9, 2008, at 3:33 AM, Jon Rosebaugh wrote: On Jan 7, 2008 2:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: 0.4.2b -- - sql - changed name of TEXT to Text since its a generic type; TEXT name is deprecated until 0.5. The upgrading behavior of String to Text when no length is present is also deprecated until 0.5; will issue a warning when used for CREATE TABLE statements (String with no length for SQL expression purposes is still fine) [ticket:912] What are we supposed to do with Unicode? just use Text(convert_unicode=True, assert_unicode='warn'). Unicode is just a shortcut for String with those flags given. We can add a corresponding UnicodeText shortcut too. Its a pretty valid use case to have a sized unicode-holding column such as a varchar; for example with utf-8 encoding you can calculate the maximum size of a particular string (the encoding used for a certain column in a DB is a constant). For folks that use databases like Oracle, the overhead of CLOB columns is very high (and theyre also not so convenient in PG and MySQL either since they cant be indexed the same way). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 7, 2008, at 7:02 PM, Mike Orr wrote: On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. the setuptools docs imply that anything alphabetically after final is a post release but I think we're going to have to go with 0.4.2r3, 0.4.2r4, etc. for the patch releases. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 8, 2008, at 3:43 AM, Mike Orr wrote: Generally a third-level number is a minor bugfix release. A second-level number indicates feature changes or backward incompatibilities. A first-level number indicates a major paradigm shift. the problem with 0.4.3, 0.4.4 etc. is that we assign those numbers as milestones in trac, and we do have a notion of a set of features that will be slowly rolled out over the course of the 0.4 series. Its really just the 0. at the beginning of the number which makes our scheme different..so it would imply that we'd have a four-level version number, i.e. 0.4.2.1 0.4.2.2 etc. (because the 0. is pretty much superfluous). But we usually dont have fourth-level versions, its only because 0.4.2 got a little more involved than a usual point release that we are in this abc thing (which note at the moment ive switched to 0.4.2r3). as far as the 0., im really glad that the 0.1 series wasnt called SQLAlchemy 1.0 , as well as that 0.2 wasnt SQLAlchemy 2.0, etc. 0.1 and 0.2 were absolutely not major-version number products. 0.4 is starting to look more major versioned to me, but if we went thru 0.4 and then jumped to 1.0, that would seem kind of brittle as well. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 8, 2008 1:13 AM, Michael Bayer [EMAIL PROTECTED] wrote: the problem with 0.4.3, 0.4.4 etc. is that we assign those numbers as milestones in trac, and we do have a notion of a set of features that will be slowly rolled out over the course of the 0.4 series. [nod] That makes sense if you're assigning versions that way. Actually, it looks like Pylons is the same. I thought it was a three-level system but the current version is 0.9.6.1. as far as the 0., im really glad that the 0.1 series wasnt called SQLAlchemy 1.0 , as well as that 0.2 wasnt SQLAlchemy 2.0, etc. 0.1 and 0.2 were absolutely not major-version number products. 0.4 is starting to look more major versioned to me, but if we went thru 0.4 and then jumped to 1.0, that would seem kind of brittle as well. Well, 1.0 also implies a long-term commitment to the API, so you don't want to do it while you're still deciding what you want. I'm glad 0.3 wasn't called 1. 0.4 and its documentation are close to the quality of a 1.0 release. But you know better than I what SQLAlchemy 1.0 should contain. Do you have a specific set of features you want in it? Or are you just going to wait until the changes slow down and then make that version 1.0? -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
On Jan 7, 2008, at 7:02 PM, Mike Orr wrote: On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. that sort of sucks, i thought easy install could recognize lettered revsions. I cant see myself calling these 0.4.3 and 0.4.4 since a point release at that level for us usually means a lot more changes and time spent in SVN. i usually use alpha and beta to indicate such ive never thought of a and b that way. of course if we moved to whole numbers, that could help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.2b released
Mike You just need pick letter that are after release. Thing like p1 is greater then release from the egg docs. (A note about versions: the egg runtime system understands typical version numbering schemes, so it knows that versions like 1.2a1 and 1.2rc5 are actually older than the plain version 1.2, but it also knows that versions like 1.2p1 or 1.2-1 are newer than 1.2.) Following a release number, you can have either a pre-release or post-release tag. Pre-release tags make a version be considered older than the version they are appended to. So, revision 2.4 is newer than revision 2.4c1, which in turn is newer than 2.4b1 or 2.4a1. Postrelease tags make a version be considered newer than the version they are appended to. So, revisions like 2.4-1 and 2.4pl3 are newer than 2.4, but are older than 2.4.1 (which has a higher release number). A pre-release tag is a series of letters that are alphabetically before final. Some examples of prerelease tags would include alpha, beta, a, c, dev, and so on. You do not have to place a dot before the prerelease tag if it's immediately after a number, but it's okay to do so if you prefer. Thus, 2.4c1 and 2.4.c1 both represent release candidate 1 of version 2.4, and are treated as identical by setuptools. Hope this helps. Michael Bayer wrote: On Jan 7, 2008, at 7:02 PM, Mike Orr wrote: On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. that sort of sucks, i thought easy install could recognize lettered revsions. I cant see myself calling these 0.4.3 and 0.4.4 since a point release at that level for us usually means a lot more changes and time spent in SVN. i usually use alpha and beta to indicate such ive never thought of a and b that way. of course if we moved to whole numbers, that could help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
