Rhett Garber wrote:
>>>
>>> Oh right, sorry:
>>>
>>> class Advertiser(Base):
>>> __tablename__ = "advertiser"
>>> id, _id = build_id_column('id', primary_key=True)
>>> salesperson_id, _salesperson_id =
>>> build_id_column('salesperson_id', foreign_key=ForeignKey("%s.id" %
>>> Salesperson._
>>
>> Oh right, sorry:
>>
>> class Advertiser(Base):
>> __tablename__ = "advertiser"
>> id, _id = build_id_column('id', primary_key=True)
>> salesperson_id, _salesperson_id =
>> build_id_column('salesperson_id', foreign_key=ForeignKey("%s.id" %
>> Salesperson.__tablename__))
>> salesper
On Apr 21, 2010, at 4:08 PM, Rhett Garber wrote:
> On Wed, Apr 21, 2010 at 6:35 AM, Michael Bayer
> wrote:
>> Rhett Garber wrote:
>>> This would be much easier, I could potentially be what we go with. I
>>> think this is similar to my 'original implementation'
>>> I just found the syntax to be
On Wed, Apr 21, 2010 at 6:35 AM, Michael Bayer wrote:
> Rhett Garber wrote:
>> This would be much easier, I could potentially be what we go with. I
>> think this is similar to my 'original implementation'
>> I just found the syntax to be a bit bothersome since the person
>> creating the table has
Rhett Garber wrote:
> This would be much easier, I could potentially be what we go with. I
> think this is similar to my 'original implementation'
> I just found the syntax to be a bit bothersome since the person
> creating the table has to know they are creating two
> columns... or not using decla
On Tue, Apr 20, 2010 at 4:32 PM, Michael Bayer wrote:
>
> On Apr 20, 2010, at 7:06 PM, Rhett wrote:
>
>> I've run into some difficulty getting the ORM to fit into an existing
>> code base with some, I suppose, non-standard conventions.
>>
>> One of the conventions is to not allow primary keys (aut
On Apr 20, 2010, at 7:32 PM, Michael Bayer wrote:
>
> if you want MyClass.encrypted_id to be available in queries at the class
> level, this would require a SQL function that does your "encryption". See
> examples/derived_attributes/ for some techniques on that.
correction, you'd probably wa
On Apr 20, 2010, at 7:06 PM, Rhett wrote:
> I've run into some difficulty getting the ORM to fit into an existing
> code base with some, I suppose, non-standard conventions.
>
> One of the conventions is to not allow primary keys (auto-incremented
> integers) to be exposed on the front-end servl
I've run into some difficulty getting the ORM to fit into an existing
code base with some, I suppose, non-standard conventions.
One of the conventions is to not allow primary keys (auto-incremented
integers) to be exposed on the front-end servlet or template
but to maintain the original integer va
