[sqlalchemy] Re: Tutorial Issue

2010-10-01 Thread LucianU
I noticed that line but didn't think it was essential. It looked more
of an aside thing, but it seems I was wrong. Anyway, I'm glad I
brought it up because someone else could have made the same mistake.
Thank you for your answer.

On Sep 30, 5:16 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 OK, was hard to spot, and I think maybe I should change this, there's a line 
 where it does this:

  users_table = User.__table__

 So the original users_table is replaced with the one that User.__table__ is 
 mapped to.

 I'm going to change that remapping to read like this:

  mapper(User, User.__table__, properties={    

 ...     'addresses':relationship(Address, backref='user', cascade=all, 
 delete, delete-orphan)
 ... })
 Mapper at 0x...; User

  addresses_table = Address.__table__
  mapper(Address, addresses_table)

 Mapper at 0x...; Address

 On Sep 30, 2010, at 6:22 AM, LucianU wrote:



  Hello, all!

  I'm following the tutorial 
  herehttp://www.sqlalchemy.org/docs/orm/tutorial.html
  and I'm running into some problems at one moment, specifically at the
  Configuring delete/delete-orphan Cascade section. Here is a paste of
  exactly what I'm doinghttp://bpaste.net/show/9861/. Am I making a
  mistake somewhere or is the tutorial incorrect?

  Lucian

  --
  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 
  athttp://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 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.



[sqlalchemy] Passing model objects to other threads

2010-10-01 Thread James
Hi all,
i'm using SQLAlchemy in a TG2 web app which has long-running jobs
kicked off by user POSTs.

I'm planning on writing the pending jobs to the DB, then kick off a
threading.Thread at the end of the web app method to actually do the
work.

Question - I'll need to pass the job description (a SA object) to the
child thread; but to use the description, I need to detach it from the
old TG2 thread's SA session, and reattach it to the child thread's SA
session, right?

How best to do that? I don't see a way of getting the current session
from a live SA object...

Thanks!
James

-- 
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.



[sqlalchemy] Re: Passing model objects to other threads

2010-10-01 Thread NiL
Hi,

have you considered using TGScheduler ?

-- 
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.



[sqlalchemy] Re: Passing model objects to other threads

2010-10-01 Thread James
Hi,
Yes I was going to have TGScheduler run at intervals to complete any
jobs that fail the first time round (as they might, for reasons I
can't control).

However, the initial job run is reasonably time-sensitive, so I would
like it to get started right as the user POSTs the instructions; but I
was thinking that having every web app instance polling the DB at
short intervals would be a lot of overhead.

That said, if TGScheduler handles the session initiation gracefully,
and I'm going to have it running anyway, I could get away with polling
a few times a minute and the user wouldn't realistically notice...

Thanks for the suggestion! If all else fails, I'll bastardise the
session initialisation code from TGScheduler to roll my own :)

James

On Oct 1, 3:11 pm, NiL nicolas.laura...@gmail.com wrote:
 Hi,

 have you considered using TGScheduler ?

-- 
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.



Re: [sqlalchemy] Passing model objects to other threads

2010-10-01 Thread Michael Bayer

On Oct 1, 2010, at 9:40 AM, James wrote:

 Hi all,
 i'm using SQLAlchemy in a TG2 web app which has long-running jobs
 kicked off by user POSTs.
 
 I'm planning on writing the pending jobs to the DB, then kick off a
 threading.Thread at the end of the web app method to actually do the
 work.
 
 Question - I'll need to pass the job description (a SA object) to the
 child thread; but to use the description, I need to detach it from the
 old TG2 thread's SA session, and reattach it to the child thread's SA
 session, right?
 
 How best to do that? I don't see a way of getting the current session
 from a live SA object...

If you're writing jobs to the DB anyway, why not use a different process to 
handle the jobs, and have it poll the jobs table, instead of passing directly ? 
  That's how I'm currently doing it.  The job runner then forks off additional 
procs to run N number of jobs simultaneously with multiprocessing.   You at 
least get true concurrency that way.

Otherwise, the general paradigm to pass state between threads uses merge(), it 
leaves the original unaffected.

obj = Session.query(...).first()

start_new_thread(obj)

# in the thread's method:

def start_my_thing(obj):
   obj = Session.merge(obj)


-- 
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.



[sqlalchemy] appropriate place for before insert

2010-10-01 Thread Landreville
I need to make a call to an external system (through SOAP) when a new
object is saved/updated/deleted. If the external call fails then I
would like the save to also fail.  I have looked at the documentation
and a MapperExtension cannot change the flush plan to cancel if the
external call fails.

I have looked at session extensions and it looks like they would work,
but it seems far removed from my object.
I would have to check each object in the session to see if it is the
correct type and then execute the external method and then remove the
object from the session if it fails. Is this the recommended way of
binding an external action when modifying an object?

I suppose I could add a before_insert method to my object and have a
session extension that just checks every object to see if it has
before_insert and if it does then execute it (and any errors would
remove the object from the session).


Thanks,

Landreville

-- 
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.



Re: [sqlalchemy] appropriate place for before insert

2010-10-01 Thread Michael Bayer

On Oct 1, 2010, at 12:30 PM, Landreville wrote:

 I need to make a call to an external system (through SOAP) when a new
 object is saved/updated/deleted. If the external call fails then I
 would like the save to also fail.  I have looked at the documentation
 and a MapperExtension cannot change the flush plan to cancel if the
 external call fails.
 
 I have looked at session extensions and it looks like they would work,
 but it seems far removed from my object.
 I would have to check each object in the session to see if it is the
 correct type and then execute the external method and then remove the
 object from the session if it fails. Is this the recommended way of
 binding an external action when modifying an object?
 
 I suppose I could add a before_insert method to my object and have a
 session extension that just checks every object to see if it has
 before_insert and if it does then execute it (and any errors would
 remove the object from the session).

Any extension, mapper or session, can cancel the operation overall by raising 
an exception, which will result in halting the flush and issuing a ROLLBACK.   
Usually, if something goes wrong inside of a transaction, the whole thing is 
rolled back since you otherwise have only a partial state of data.

Inside of mapper extension, a simplistic dont update the row operation may be 
possible if you just expired the attributes of the instance inside of 
before_update(), though I haven't tried this and it wouldnt really work for 
inserts or deletes anyway.

Within session extension, its common to search for objects by traversing 
through the .new, .dirty and .deleted collections. 0.7 will be expanding on 
this model by providing event listener hooks that do this filtering for you, 
sending only objects of the desired type to the listener, and from that it 
follows that we can eventually optimize the search by improving the bookkeeping 
performed by these collections.SessionExtension is definitely the more 
generic choice overall these days for flush events.   the use cases for 
MapperExtension are much smaller.




-- 
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.



[sqlalchemy] Re: appropriate place for before insert

2010-10-01 Thread Landreville


On Oct 1, 12:54 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 Any extension, mapper or session, can cancel the operation overall by raising 
 an exception, which will result in halting the flush and issuing a ROLLBACK.  
  Usually, if something goes wrong inside of a transaction, the whole thing 
 is rolled back since you otherwise have only a partial state of data.

 Inside of mapper extension, a simplistic dont update the row operation may 
 be possible if you just expired the attributes of the instance inside of 
 before_update(), though I haven't tried this and it wouldnt really work for 
 inserts or deletes anyway.

 Within session extension, its common to search for objects by traversing 
 through the .new, .dirty and .deleted collections.     0.7 will be expanding 
 on this model by providing event listener hooks that do this filtering for 
 you, sending only objects of the desired type to the listener, and from that 
 it follows that we can eventually optimize the search by improving the 
 bookkeeping performed by these collections.    SessionExtension is definitely 
 the more generic choice overall these days for flush events.   the use cases 
 for MapperExtension are much smaller.


Sounds good. I suppose I would most often raise an exception to
rollback the entire flush, but in rare cases I might want to go ahead
and save the rest of the object I would just detach one from the
session and delete it.

Thanks for you reply,

Landreville

-- 
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.



[sqlalchemy] Building queries programmatically

2010-10-01 Thread Edward Williams
Hi,

I'm working on an application where queries are created completely by
the user. (The goal is to make it easy for the user). Because of this
I have to support dynamic query creation and manipulation. My current
model has a query class with my own created specification for queries
which is manipulated by the user via the GUI. This is then turned into
an SQLA query when it's run. Well, it will be turned into one.

I'm trying to wrap my head around building the WHERE clause. I find
that when a function returns a condition (age  18 for example) it
comes with brackets around it. However, when I enter it into the where
function directly it doesn't unless it uses an SQLA method like
column.in_(stuff) .

I have some test code I've been playing with below:

def condition(age,b):
return age  b

name = tableObjects['users'].c['name']
age = tableObjects['users'].c['age']
password = tableObjects['users'].c['password']
q = select([tableObjects['users']])
names = ('Mark','Joel')
#the query construction
a = (name.in_(names))

# I enter it into the where method directly:
q = q.where(name.in_(names)+age18+~password.like('v'))
#Results in:
#WHERE (users.name IN (?, ?)) + users.age  ? + (users.password NOT
LIKE ?)

# If functions build the term:
expr = name.in_(names) + condition(age,18)
q = q.where(expr)   # If placed in where(expr) it results in WHERE
(users.name IN (?, ?)) + (users.age  ?)
# Note extra brackets
result = dataConnections['sqlite:///tutorial.db'].execute(q)
for row in result:
print row

Would the brackets make any difference to the performance? (They
wouldn't make any meaningful difference to the result as far as I can
see)

I've recently noticed the serializer for SQLA queries. How easy would
it be to save them with IDs? Also, is it easy to manipulate and adjust
a specific piece of a query? Like, the second element of a nested
where clause? If it is, my separate class system may be unnecessary
overhead (unless I decide the ability to port to other libraries is
really important...).


Thanks,
Edward

-- 
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.