It's amazing how even a little time to think clarifies - The most compelling reason to NOT make a blanket DAL column renaming behind the scenes is that you will NEVER be able to read existing databases. Currently, people are often unhappy enough about the "id" field naming convention, and the limitations it places on use of existing db's.
Combining these two issues, this comes to mind (I think from a developer's perspective, this captures what people have said they want over time): FIRST: 1 - allow configuring the "id" field, on a per-database (per table???) basis. This would let people configure their DAL statements to work with, provide adjunct processing (including updates) without needing to configure a view to do the mapping. I imagine to make prototypes / demo's for customers (even internal) will be much easier with this. Something like: db.id = "id" reads nice for the default. A heirarchical overide like this might be nice (if I think of this in terms of a table class that inherits this from a db class that has a default that is what we currently have - "id" this seems like a straightforward implementation).: db.users.id = "user_id" also works well. What would this affect? - I can think of all the places where there is "id" in current code - people complaining, BUT literals should not have been used in the first place for builting values like this - and this is percisely why. the class accessor instead of a literal string! SECOND: 2 - For all the databases supported, have sql.py hold all the reserved db words for that database, and HELP the developer (especially since this varies by database) by raising exceptions when trying to access a keyword, and a warning when accessing a reserved word. Why? Because if I have a solution (even if I buy one from one of the people on this group), and my target DB changes for a client, I'll not have to STUMPLE into problems - I'll know them up front. An option (for testing) would be to scan your table decrarations against ALL supported db's ... Now, this is not "interesting" work to add to web2py, but it would be useful. Your thoughts? Regards, Yarko On Nov 10, 10:35 am, "Yarko T" <[EMAIL PROTECTED]> wrote: > yes... something about if "foo" is reserved, the form "foo_" is > guarenteed to never be a reserved word.... (something like that). > I made to argument that in web2py we should use whatever words we want, with > no worries, and KNOW, announce, have the DAL uniformly convert ALL database > field names to the form "foo_" > > Massimo made some argument against that ... I don't remember what it was or > it's strenghth... .but maybe this is enough context to start from if you > want to re-visit this. > > Yarko > > On Mon, Nov 10, 2008 at 9:22 AM, billf <[EMAIL PROTECTED]> wrote: > > > I don't think you can. I'd be happy to be proved wrong. > > > There was a thread a while ago about how it would be really nice to be > > able to map a database column name to an 'internal' name. This was > > primarily to help with legacy tables that had unfriendly column > > names. In the context of Firebird/T2, I guess you could redefine the > > T2.person table with a column name other than password and map it to > > 'password' internally. > > > Having said that we don't have an "map" facility yet :-) > > > On Nov 10, 2:47 pm, Jose <[EMAIL PROTECTED]> wrote: > > > Hello. > > > > How can I change the name of some fields when I use T2? > > > There are some of them that correspond to words reserved of Firebird, > > > for example password. > > > > Regards > > > Jose --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
