[sqlalchemy] RE: - iPhone App To Help You Regain 20/20 Vision Naturally

[Twenty Twenty Vision]

RE: - http://isra.li/2020vision - "20/20 Vision" is an iPhone app that will 
help you regain 20/20 vision naturally, by looking at images that relaxes your 
eyes and performing eye exercises that strengthen your eyes, anywhere within 
your busy life (i.e. office cubicle, crowded subway, waiting at the hair salon, 
etc.), thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@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.

Re: [sqlalchemy] Creating a feed related to different object type

[Brice Leroy]

Hi Eric,

Thank you, I actually used this documentation (even though they are only
many-to-many) and some other blog post to come up with this solution. Using
0.7 I don't have event on Mixin so I had to find an alternative to event
attachment. BTW I'm pretty surprised by the speed of the event solution
provided by SQLAlchemy, as I always heard that event listener on DB object
were evil, but it turned out to almost add no overhead (test operated 2k
object creation).


On Sat, Dec 1, 2012 at 10:35 PM, Eric Ongerth  wrote:

> Hi Brice,
>
> Yours is another good case of the 'Generic Associations' or 'Polymorphic
> Association' pattern which comes up quite often.  Here's a link to some
> docs that will get you going on a good solution that keeps the database
> normalized.
>
>
> http://docs.sqlalchemy.org/en/rel_0_8/orm/examples.html#generic-associations
>
> If that doesn't get you off and running, especially the example in
> discriminator_on_association.py, continue this thread or pop into the IRC
> channel.
>
> - ejo
>
>
> On Wednesday, November 28, 2012 1:20:52 PM UTC-8, deBrice wrote:
>
>> So here is my solution,
>>
>> https://gist.github.com/**4164619 
>>
>> Hope it helps others to get an insight on generic relation in SQLAlchemy.
>>
>>
>> On Tue, Nov 27, 2012 at 7:41 AM, Brice Leroy  wrote:
>>
>>> Thank you for the advice Robert. As I'm using flask I'm not sure how
>>> adaptable the ZCA would be. I'll try to understand the logic behind it and
>>> see if I can replicate it within my models.
>>>
>>>
>>> On Tue, Nov 27, 2012 at 7:12 AM, Robert Forkel 
>>> wrote:
>>>
  hi,
 i used to do something like this, i.e. adding information about urls,
 views, etc. to sqlalchemy models, but found this to be inflexibel. Now
 I keep URL-related information in the web app's routing component, and
 to solve problems like the one you pose, I use zca adapters [1] (which
 is easier when using pyramid, because you already have a component
 registry available). So with this technology you'd register the same
 FeedItem class as adapter for the various sqlalchemy models, which
 means that at adaption time, the object to adapt will be passed to
 you.
 regards
 robert

 [1] 
 http://www.muthukadan.net/**docs/zca.html


 On Tue, Nov 27, 2012 at 3:58 PM, Brice Leroy 
 wrote:
 > Hello everybody,
 >
 > It's about brainstorming on an elegant solution. I previously posted
 this
 > question on the Flask mailing list, and I got advised to post it on
 > SQLAlchemy list... which make more sense I admit. So here is my issue:
 >
 > I have N different classes:
 >
 > class Comment(Models):
 >   author_id = Integer
 >   comment = String
 >   creation_date = Date
 >
 > class Picture(Models):
 >   author_id = Integer
 >   image = File
 >   creation_date = Date
 > ...
 >
 > now let say, I have a "follow" feature, allowing a user X to get
 updates
 > when Y (the user followed by X) does something (creepy...).
 >
 > So far I came up with something like that:
 >
 > class FeedItem(Model)
 >   table = String
 >   key = Integer
 >   creation_date = Date
 >
 >   def url(self):
 > #get object by querying self.table with self.key
 > object = self.get_an_object(table=self.**table, key=self.key)
 > return object.view_url
 >
 > and then add this property to Comment and Picture classes:
 >
 >   @property
 >   def view_url(self):
 > return url_for('view_function_name', self.id)
 >
 > - What would be your way of dealing with this kind of "open/generic"
 > relationship items?
 >
 > - How would you manage automatic deletion of a FeedItem when the
 object it
 > points to get destroyed? (I'm thinking attaching function on delete
 event to
 > classes)
 >
 > - Would you create as many FeedItem per follower, or use a Table to
 link
 > them to followers, therefore deleting a FeedItem would automatically
 delete
 > the relation record from the Table.?
 >
 > Thank you,
 >
 > --
 > Brice
 >
 > --
 > You received this message because you are subscribed to the Google
 Groups
 > "sqlalchemy" group.
 > To post to this group, send email to sqlal...@googlegroups.com.

 > To unsubscribe from this group, send email to
 > sqlalchemy+...@**googlegroups.com.

 > For more options, visit this group at
 > http://groups.google.com/**group/sqlalchemy?hl=en
 .

 --
 You received this message because you are subscribed to the Google
 Groups "sqlalchemy" group.
 To post to this group, send email to sqlal...@googlegroups.com.
 To unsubscribe from this group, send email t

Re: [sqlalchemy] alembic handles no primary key table

[Michael Bayer]

On Dec 2, 2012, at 5:00 PM, junepeach wrote:

> Michiael, I don't have a Metadata yet.

yes you do, your Base has one as Base.metadata

> So, should we add a primary for this non-primary key table? Thanks you very 
> much!

if you don't want the table having a primary key, then don't add a primary key 
to it.


-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@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.

Re: [sqlalchemy] Using Guid as Primary Key

[Michael Bayer]

On Dec 2, 2012, at 4:30 PM, Wolfgang Keller wrote:

>> Can I use the Guid as primary key? I am newbie to sql and mysql
>> management. 
> 
> Using such auto-generated surrogate keys is always a really bad idea
> and the straightest and shortest way to data inconsistency hell
> (especially through duplicates).

you've seen two guids generate as duplicates ?  the chances of that are smaller 
than something one would ever see in 100K years.

guids aren't very efficient when it comes to indexes on foreign key/primary key 
columns though, they take up a lot of space.

anyway you can use GUIDS in sqlalchemy just like:

import uuid
Column(String(32), default=lambda: uuid.uuid4().hex, primary_key=True)


-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@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.

Re: [sqlalchemy] Application locking and SQLAlchemy

[YKdvd]

D'oh!  And I had just been reading the docs about a commit expiring loaded 
object instances, which is what the refresh() would have done.  So the mere 
accessing of that User object instance (say, UserObj.name=newNameFromEdit, 
or temp=UserObj.name) would first trigger a reload of that User from the 
database, once I've committed my lock-obtaining inserts to the Locks table 
based on an initial Users query.  

By the way, add me to the list of grateful SQLAlchemy users.  I've played 
with Doctrine in PHP a bit, and if nothing else the SQLA documentation is 
miles better.  As a starter it is mainly a magical way of replacing writing 
a pile of tedious CRUD, and as someone who has hazy memories of things like 
the original Btrieve, an ORM is almost unsporting... :)

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sqlalchemy/-/-LdgqLa40rYJ.
To post to this group, send email to sqlalchemy@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.

Re: [sqlalchemy] alembic handles no primary key table

[junepeach]

THanks Werner and Michiael. Yeah ORM requires a primary key for every table. 
Michiael, I don't have a Metadata yet. I am creating a migration script to be 
shared among several databases. We will use this script to create tables schema 
in several databases. So, should we add a primary for this non-primary key 
table? Thanks you very much!

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sqlalchemy/-/9O5OzYRSiDAJ.
To post to this group, send email to sqlalchemy@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.

Re: [sqlalchemy] Using Guid as Primary Key

[Wolfgang Keller]

> Can I use the Guid as primary key? I am newbie to sql and mysql
> management. 

Using such auto-generated surrogate keys is always a really bad idea
and the straightest and shortest way to data inconsistency hell
(especially through duplicates).

Sincerely,

Wolfgang 

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@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.

Re: [sqlalchemy] Application locking and SQLAlchemy

[Michael Bayer]

On Dec 2, 2012, at 3:29 PM, YKdvd wrote:

> I'm starting to use SQLAlchemy to access a small, in-house database.  I need 
> to add some rudimentary concurrency handling, and just wanted to see if my 
> general impression as to the SQLAlchemy implications are correct.  As a 
> hypothetical  example, assume something like a Users table, and some sort of 
> grid-like editing display displaying multiple rows.  My intention is to 
> create a "Locks" table, which identifies the 
> table/primaryID/lockObtainedTimestamp of a locked row in a data table like 
> Users.  An editing routine would have to acquire locks for the rows it wished 
> to edit.  There's three basic cases:
> 
> 1) Exclusive editor - I'd just obtain a Locks on some unique identifier 
> specific to, say, editing Users, and only one editor would be allowed to 
> update Users at a time.  This is just a simple semaphore, and once obtained I 
> can do all my SQLAlchemy stuff freely, since it is assumed nothing else will 
> write to the data table.  The existing non-DB scheme does this, although I'll 
> be able to change this to case #2.
> 
> 2) Entire grid - once the desired subset of records have been retrieved 
> (perhaps all Users in a particular group or branch office), the grid enables 
> all records to be modified, with a single "Update" once finished.  Here I'd 
> have to loop through the Users returned from my SQLAlchemy query, and obtain 
> a Locks for each one (one Locks row per User).  If successful, I'd then have 
> to call refresh() for each of the objects (just in case something updated 
> between query and obtaining the lock).
> 
> 3) Single row - only one grid row is edited/saved at a time, so I'd just 
> obtain a Locks for it and refresh() the single object before editing. 
> 
> I'm pretty sure I know what I need to make the Locks table work, but I just 
> wanted to be sure that refresh() is the right SQLAlchemish thing to do in 
> this situation.  This would be low-volume, in-house sort of thing, and this 
> type of basic pessimistic locking is acceptable over trying to resolve an 
> editing conflict using the built-in optimistic version_id_col / 
> StaleDataError features, although that may be useful in places.

refresh() is usually not the right way to go, as most relational databases will 
have you sitting in a transaction that has some degree of isolation from what's 
going on outside, so the SQLAlchemy way is to think in terms of transactions 
and units of work.The Session expires all state after a transaction ends, 
and queries in the subsequent transaction will re-query the database to get the 
most recent state.The simplest way to build a system like this is to create 
a Session to handle reading/acquiring locks, run through the lock rows needed, 
then commit.   If you'd like to prevent any particular "lock" operation from 
interfering with another, you can run the transaction on that particular 
Session with serializable isolation, which is available as an execution option 
on Connection (See 
http://docs.sqlalchemy.org/en/rel_0_8/core/connections.html?highlight=execution_options#sqlalchemy.engine.Connection.execution_options).


-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@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.

[sqlalchemy] Application locking and SQLAlchemy

[YKdvd]

I'm starting to use SQLAlchemy to access a small, in-house database.  I 
need to add some rudimentary concurrency handling, and just wanted to see 
if my general impression as to the SQLAlchemy implications are correct.  As 
a hypothetical  example, assume something like a Users table, and some sort 
of grid-like editing display displaying multiple rows.  My intention is to 
create a "Locks" table, which identifies the 
table/primaryID/lockObtainedTimestamp of a locked row in a data table like 
Users.  An editing routine would have to acquire locks for the rows it 
wished to edit.  There's three basic cases:

1) Exclusive editor - I'd just obtain a Locks on some unique identifier 
specific to, say, editing Users, and only one editor would be allowed to 
update Users at a time.  This is just a simple semaphore, and once obtained 
I can do all my SQLAlchemy stuff freely, since it is assumed nothing else 
will write to the data table.  The existing non-DB scheme does this, 
although I'll be able to change this to case #2.

2) Entire grid - once the desired subset of records have been retrieved 
(perhaps all Users in a particular group or branch office), the grid 
enables all records to be modified, with a single "Update" once finished. 
 Here I'd have to loop through the Users returned from my SQLAlchemy query, 
and obtain a Locks for each one (one Locks row per User).  If successful, 
I'd then have to call refresh() for each of the objects (just in case 
something updated between query and obtaining the lock).

3) Single row - only one grid row is edited/saved at a time, so I'd just 
obtain a Locks for it and refresh() the single object before editing. 

I'm pretty sure I know what I need to make the Locks table work, but I just 
wanted to be sure that refresh() is the right SQLAlchemish thing to do in 
this situation.  This would be low-volume, in-house sort of thing, and this 
type of basic pessimistic locking is acceptable over trying to resolve an 
editing conflict using the built-in optimistic version_id_col / 
StaleDataError features, although that may be useful in places.


-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sqlalchemy/-/U-jpoIxGoNoJ.
To post to this group, send email to sqlalchemy@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.

[sqlalchemy] Using Guid as Primary Key

[Gops S]

Can I use the Guid as primary key? I am newbie to sql and mysql management. 

I am worried about auto-generation of primary when it is defined as integer 
when we backup and restore the database. 

Can anyone throw light on using auto-increment id as primary key vs using 
guid string id as primary key?

Thanks,

Gopal

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sqlalchemy/-/YPhwOqvdG2gJ.
To post to this group, send email to sqlalchemy@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.