Great. I'll watch for the DAL changes.
On Jun 26, 11:53 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> This is complicated and with the current DAL I am not sure myself what
> it would break. I am rewriting the DAL to be more modular and allow
> mapping between virtual names and actual names. This will be possible
> then.
>
> Massimo
>
> On Jun 26, 9:07 am, brado <br...@movedbylight.com> wrote:
>
> > Legacy databases without Id fields: a lightweight proposal.
>
> > I plan to pluck information from a live Drupal site into a Web2Py
> > site, and I love Web2Py's compact database layer.
>
> > Drupal designs it's tables with an autoincrementing integer primary
> > key, which agrees with gluon.sql, but it names them differently, like
> > 'nid' (node id), or 'uid' (user id), which gluon.sql won't accept.
>
> > Let's NOT get into another synthetic key vs. natural key debate. It's
> > an old argument with bright people on both sides who won't be
> > convinced (well, perhaps after we decide "What's the best editor?").
> > Personally, I applaud web2py's design decision to always require a
> > synthetic key (the implicit 'id' field). It keeps the DAL relativley
> > small and comprehensible. If I need natural keys, I'll use SQLAlchemy,
> > and the web2py site graciously show how to do this, and that may well
> > be what I end up doing.
>
> > I am considering patching sql.py for my own use when I want to access
> > existing tables that follow web2py's design, but not it's naming
> > convention. That is, they have 'id', but they name it something else.
>
> > Here are the proposed changes, all in gluon.sql:
>
> > 1. Replace the string literal 'id' with an attribute of SQLTable like
> > self.id_field_name. (Careful not to replace locations where 'id' is a
> > field type rather than a field name.
>
> > 2. Add a named arg to the table constructor: SqlTable(...,
> > id_field_name='id') which would change the value of that attribute.
>
> > 3. Change SQLTable.__getattr__ to read:
>
> > def __getattr__(self, key):
> > if key=='id':
> > return dict.__getitem__(self, self.id_field_name)
> > return dict.__getitem__(self,key)
>
> > Seems like a good idea, but my head isn't in the code to fully know
> > what it would break. Does anybody see glaring red flags in this?
--~--~---------~--~----~------------~-------~--~----~
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
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
