Re: [SQLObject] Proposal: change .get(int) to .get_id(int)

[Mike W. <li...@mi...>]

On Wed, 2004-07-21 at 23:53, Luke Opperman wrote: 
> Quoting Mike Watkins <li...@mi...>:
> 
> > Proposal: change .get(int) to .get_id(int)
> I can see the naming clash, although there's a lot to implement to adapt an SO
> class to a dictionary interface - with some conceptual mismatches in my mind.
> Do you really need it to act like a dictionary, or do you just like the
> semantics of the dict.get() call

SQLObjects act like a dict now; I just wanted the flexibility to use
whatever I want for .get() so that when I do need an object that looks
and acts like a dict with a string based key, without changing the
internal mechanism SQL object uses for a key value - I can.
        
get() / keys() / values() / items() / has_hey() are used so frequently
in python, I thought it would be nice if we could make our SQLObjects
look the same, when it makes sense - but the current use of .get() gets
in the way.
     
Here's my prototypical example:

Folder(SQLObject) 
    # id implied, serial integer
    # references maintains the hierarchical relation
    references = ForeignKey('Folder', dbName='references_id')
    key = StringCol(length=255)
    title = StringCol()
[snip]
    
    def get(key):
        return Folder.select(Folder.q.key == key, Folder.q.referencesID==self.id)
        
    def has_key(key):
        result = Folder.select(Folder.q.key == key, Folder.q.referencesID==self.id)
        assert result.count() <= 1  # should never have more than one
        if result.count() == 1:
            return True

    def keys():
    def values():
    def items():
    def add_folder(key, title):
        return Folder.new(referencesID=self.id, key=key, title=title)
[snip]

The "id" attribute is a standard Postgres SERIAL integer sequence and is
the "real" sql key value. In this case I'm wanting to hid all this
behind a dict-like interface, which if I could would inlucde get() as
well as has_key() etc because I don't want accesses directly to objects
by their SQL key value. And in psuedo code, accessing the tree:
root = Folder()

    root.keys()
        'subfolder','another','mike','frank','sue'
        mike.keys()
            'documents','events','blah'


mikesdocfolder = mike.get('documents')

Just feels nice.

Agreed this is an implementation issue, the current scheme does nothing
to prevent me from implementing a workable solution. My comment was
merely that it would be nice if SQLObject out of the box would allow us
to make objects look as pythonic as possible, when the feeling moves us.

I can see this being of value when objects are being shared across
systems, projects or working teams - here, take my Folder() - and show
them the dict-like interface and most people would know how to use it


--
Mike

Q: How many existentialists does it take to screw in a lightbulb? A:
Two. One to screw it in and one to observe how the lightbulb itself
symbolizes a single incandescent beacon of subjective reality in a
netherworld of endless absurdity reaching out toward a maudlin cosmos of
nothingness.