On Tue, Apr 20, 2010 at 4:32 PM, Michael Bayer <mike...@zzzcomputing.com> 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 (auto-incremented
>> integers) to be exposed on the front-end servlet or template
>> but to maintain the original integer values inside 'logic' or 'back-
>> end' code.
>>
>> We've been through a few methods of trying this, but they feel like
>> we're fighting sqlalchemy and must be missing something.
>
>
> In Python, the closest thing we have to a "private" attribute is that it
> begins with an underscore. This is extremely easy to do, just name the
> mapped attribute "_id" or whatever name you'd like. This is documented at
> http://www.sqlalchemy.org/docs/mappers.html#customizing-column-properties .
>
>> The plan is to flip a flag when the object passes through a pre-
>> defined barrier, converting these columns only when they are asked
>> for.
>>
>> The original implementation had us creating two columns, one of them
>> being a synonym which provides the encryption
>> behavior, but this means we have class that look like this:
>> class Foo(Base):
>> id, _id = build_id_column(Integer, primary_key=True)
>
> where does "encryption" come into play ? are you trying to just expose
> the "primary key" value as something else ? easy enough, just use a
> descriptor:
I probably should have said 'obfuscation'. You are correct, we're
trying to make the "primary key" not expose the actual
size/distribution of the underlying table.
>
> class MyClass(object):
> def encrypted_id(self):
> return encrypt_my_id(self._super_secret_id_attribute)
>
> def set_encrypted_id(self, id):
> self._super_secret_id_attribute = unencrypt_id(id)
>
> encrypted_id = property(encrypted_id, set_encrypted_id)
>
> mapper(MyClass, mytable, properties={
> '_super_secret_id_attribute':mytable.c.id
> })
>
> 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.
So the point is that this should be done outside of the core ORM as a
standard property as opposed to getting the ORM to
do it for me. The downside being that the syntax isn't quite as clean
as using declarative.
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 declarative. These ids are (and foreign keys)
mean you'll be doing something like this multiple
times on every table in our system, so I want it to be a streamline
and foolproof as possible.
Thanks for your help,
Rhett
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
