Re: quoting entity and attribute names

    Hi John,

  Since it is needed *now* then go for it :)

Put differently, this means: I'm sorry, but I won't have the time to look at
this tonite, so just make it the way you feel it should be done, and then I'll
argue if I think it needs to be discussed !-)

-- Sébastien.

John Lenton <[email protected]>:

> Sender: John Lenton <[email protected]>
> 
> On Wed, Jun 23, 2004 at 07:54:02PM +0200, Sebastien Bigaret wrote:
> > 
> > John Lenton <[email protected]> wrote:
> > > In a project I'm currently working on there is a class that we'd like
> > > to call "User", but we can't call it that and use Modeling in its
> > > current state: it's not quoting the names of entities (nor
> > > attributes), and user is a reserved word.
> > > 
> > > I looked into it, and I actually got it working, but I then saw that
> > > in SQLExpression there's a method `externalNameQuoteCharacter'; is the
> > > purpose of this method to be used (something like) this:
> > > 
> > >     [ in _addTableJoinsForAlias ]
> > > 
> > >     quoteChar = self.externalNameQuoteCharacter()
> > >     str += quoteChar + self._internals.entityExternalNameForAlias(alias)
> + quoteChar + ' ' + alias
> > > 
> > > ?
> > 
> > And to answer this very precisely, I do not feel really comfortable with
> > quoting external names when unneeded; the quoting should IMHO be done
> > only when a whole SQL statement is returned, not during intermediate
> > steps. This makes assembleDelete|Select|UpdateStatement() methods good
> > candidates, doesn't it?
> 
> agreed on the first point, but not on the second: assembleFoo takes a
> 'tableList' parameter that is already a (list of) table name(s). For
> the singular case this wouldn't be a problem, but in the case of
> select at least it very much is (IMVHO). I think the place to do this
> would be, for table names, tableListWithRootEntity (possibly via a
> 'quoted' parameter?); however, this implies that
> _addTableJoinsForAlias must behave similarly. For attribute names it
> seems the functionality should be in sqlStringForAttribute, but that
> might be too generic.
> 
> comments? I'm moving ahead with this implementation, but I understand
> it might have to be redone in some other way (time presses *now* :) )
> 
> -- 
> John Lenton ([email protected]) -- Random fortune:
> A vacuum is a hell of a lot better than some of the stuff that nature
> replaces it with.
> 		-- Tennessee Williams
> 





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com