Re: [sqlalchemy] python customer function
thanks for point me to this docs, Jonathan, I'm going to take a look at it. j On 08/05/2015 23:30, Jonathan Vanasco wrote: Would you be able to use a TypeDecorator? http://docs.sqlalchemy.org/en/latest/core/custom_types.html#sqlalchemy.types.TypeDecorator That will allow you to define a function for handling how sqlalchemy inserts and accesses the data from sql. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com mailto:sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com mailto:sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Abort Query
Hi If I execute a query, is there a way to abort that query and release the server before the query completes? e.g. theTable = Table(‘some_large_table’, metadata, autoload=True) query = theTable.select() results = query.execute().fetchall() Is there a way that perhaps another thread, if handed the query object or something else could intervene and kill the query execution? This is so I can handle rogue queries that are taking a very long time - I want to be able to kill them before they compete. Cheers Warwick -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] possible way of changing the relationship loading strategy in the runtime, on the class level or instance level
On 5/11/15 5:50 AM, Geo wrote:
I have a base class node:
class Node:
parent= relation(
'Node',
remote_side=[id],
backref=backref(
'children',
collection_class=ordering_list('position'),
order_by=[position],
cascade='all'
)
)
by default the node.children give me a eager loading collection, and
what I want is to have a subclass of the Node but only change the
loading to lazy='dynamic' so on the
sqlalchemy.orm.dynamic.AppenderQuery I can control the loading on the
runtime. Or If I can work on the instance level? I read
the documentation but I can't figure out setting the behaviour for
my case.
eager or lazy loading can be controlled using query loader options,
however the dynamic loader specifically isn't compatible with loader
options because it changes the behavior of the attribute at the instance
level using an alternate descriptor.Just build a separate
relationship that has dynamic as the loader strategy and use that one
when you want that behavior.
--
You received this message because you are subscribed to the Google
Groups sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sqlalchemy+unsubscr...@googlegroups.com
mailto:sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com
mailto:sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Abort Query
I found this: http://stackoverflow.com/a/325528/34549 also Alex Martelli is pretty -1 on the whole idea: http://stackoverflow.com/a/1227814/34549 I'm not sure what else you'd have in mind other than interrupting the thread from the outside. On 5/11/15 2:36 AM, Warwick Prince wrote: Hi If I execute a query, is there a way to abort that query and release the server before the query completes? e.g. theTable = Table(‘some_large_table’, metadata, autoload=True) query = theTable.select() results = query.execute().fetchall() Is there a way that perhaps another thread, if handed the query object or something else could intervene and kill the query execution? This is so I can handle rogue queries that are taking a very long time - I want to be able to kill them before they compete. Cheers Warwick -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Best practices to test a webapp using scoped_session with defined scope
On 5/11/15 6:21 AM, José Luis Lafuente wrote:
Maybe not the best title, but I'll try to explain the problem.
I'm using sqlalchemy and pyramid on my app. I'm using a scoped_session
on every request:
from pyramid.threadlocal import get_current_request
Session = scoped_session(sessionmaker(), scopefunc=get_current_request)
I want to write some functional tests, I'm using py.test for it:
import pytest
from myapp import Session, Model
@pytest.fixture(scope='function')
def webapp(request):
from myapp import main
from webtest import TestApp
app = main({}, **settings)
Session.begin(subtransactions=True)
def fin():
Session.rollback()
Session.remove()
request.addfinalizer(fin)
return TestApp(app)
def test_search(webapp):
Session.add(Model(name='dummy'))
res = webapp.get('/', status=200)
assert res.body == 'something'
The problem I have with this code is inside the web request to '/'. I
query Session for the new model, but nothing is found. However, this
assert will success:
assert Session.query(Model).filter_by(name='dummy').one().name == 'Aa'
I think the problem is related to the argument
'scopefunc=get_current_request' of the scoped_session, and the fact
that the point where I add the model have a different scope that the
web request.
To solve it, I'm patching the session this way:
...
from sqlalchemy.util import ThreadLocalRegistry
@pytest.fixture(scope='function')
def webapp(request, monkeypatch):
monkeypatch.setattr('myapp.Session.registry',
ThreadLocalRegistry(Session.session_factory))
...
Is it a correct way? Are there better ways to add models to the
database for a functional test, rolling back them afterwards?
I'm not sure why you need to do something with thread local inside of
a test, as I wouldn't expect to support test suites that run
concurrently in multiple threads. If you're looking for a test
fixture where the thing surrounding all of it is the transaction, you
should create the transaction using the Core API, then associate all
sessions with that connection/transaction. The example at
http://docs.sqlalchemy.org/en/rel_1_0/orm/session_transaction.html#joining-a-session-into-an-external-transaction-such-as-for-test-suites
illustrates this approach in the general sense. In this case, with the
global scoped_session() you probably can just patch in an alternate
sessionmaker that includes the target Connection as the bind, or even
call myapp.Session.configure(bind=my_connection), though you'd have to
revert bind to its former value afterwards.
Thanks,
JL
--
You received this message because you are subscribed to the Google
Groups sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sqlalchemy+unsubscr...@googlegroups.com
mailto:sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com
mailto:sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] possible way of changing the relationship loading strategy in the runtime, on the class level or instance level
I tested on class level and the inspect function, sth like this:
inspect(FilmNode).add_property(children_lazy, relation(
Film,
remote_side=[FilmNode.id],
lazy='dynamic',
uselist=True
)
)
and
class FilmNode(Node):
children_lazy = relation(
'Film',
remote_side=[id],
lazy='dynamic',
uselist=True
)
It worked both way, I prefer the class level definition :-). By the way,
the *Film* and *FilmNode* are both sub class of Node, and FilmNode has one
-- many relationship to Film.
Thanks Michael!!
On Monday, May 11, 2015 at 11:23:17 PM UTC+8, Michael Bayer wrote:
On 5/11/15 11:16 AM, Geo wrote:
Ok, I got this working by adding the following code into the base class:
parent_lazy = relation(
'Node',
remote_side=[id],
backref=backref(
'children_lazy',
collection_class=ordering_list('position'),
order_by=[position],
cascade='all',
lazy='dynamic')
)
The I can use node.children_lazy to get a dynamic loader. I still have
one question, am I able to add this dynamic loader by sub classing the
Node? As the base class code is from the upstream, I'm wondering if I can
have this feature without touching the base class.
If the Node is mapped using the declarative system, then subclassing it is
going to create a new mapper which links to the original using single-table
mapper inheritance. You might be able to do that, though this would have
the wrinkle that the existing self-referential relationships on Node would
still return the superclass that does not have your attribute.
More directly would be to add the new property to the original mapper, but
that adds it to that mapping globally, the way to do that which is agnostic
of whether or not declarative is used is
inspect(Node).add_property(children_lazy, relationship(Node, ...)).
On Monday, May 11, 2015 at 10:54:24 PM UTC+8, Michael Bayer wrote:
On 5/11/15 5:50 AM, Geo wrote:
I have a base class node:
class Node:
parent = relation(
'Node',
remote_side=[id],
backref=backref(
'children',
collection_class=ordering_list('position'),
order_by=[position],
cascade='all'
)
)
by default the node.children give me a eager loading collection, and
what I want is to have a subclass of the Node but only change the loading
to lazy='dynamic' so on the sqlalchemy.orm.dynamic.AppenderQuery I can
control the loading on the runtime. Or If I can work on the instance level?
I read the documentation but I can't figure out setting the behaviour for
my case.
eager or lazy loading can be controlled using query loader options,
however the dynamic loader specifically isn't compatible with loader
options because it changes the behavior of the attribute at the instance
level using an alternate descriptor.Just build a separate relationship
that has dynamic as the loader strategy and use that one when you want
that behavior.
-- You received this message because you are subscribed to the Google
Groups sqlalchemy group. To unsubscribe from this group and stop
receiving emails from it, send an email to
sqlalchemy+...@googlegroups.com. To post to this group, send email to
sqlal...@googlegroups.com. Visit this group at
http://groups.google.com/group/sqlalchemy. For more options, visit
https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google
Groups sqlalchemy group. To unsubscribe from this group and stop
receiving emails from it, send an email to sqlalchemy+...@googlegroups.com
javascript:. To post to this group, send email to
sqlal...@googlegroups.com javascript:. Visit this group at
http://groups.google.com/group/sqlalchemy. For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Merge table args from multiple mixins
Is there any clean way to get indexes, constraints etc. from multiple mixin classes? I've tried adding a declared attr for __table_args__ but apparently it follows the normal MRO and only uses one of those methods. On Stack Overflow, I've found http://stackoverflow.com/a/23429892/298479 but that looks pretty hack-ish. Cheers Adrian -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
