that is an immensely complicated query and I couldn't tell you what's going on
with that being the only context provided, unfortunately.
On Fri, Mar 18, 2022, at 10:16 PM, Michael Bukachi wrote:
> Hello,
>
> So I've got a very weird when trying to set up caching using dogpile based on
> the
Hello,
So I've got a very weird when trying to set up caching using dogpile based
on the examples provided. I'm using the latest version of SQLAlchemy 1.4.
For some strange reason using selectinload and attempting to cache the
frozen result is causing http://www.sqlalchemy.org/
To post
Michael Bukachi
5:11 AM (now)
to sqlalchemy
Hello,
So I've got a very weird when trying to setup caching using dogpile base on
the examples provided. For some strange reason using selectinload is
resulting in http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal,
On Thu, 15 Nov 2018 at 16:41, Mike Bayer wrote:
> >
> > But then you lose the benefits of the cache, and the Bakery is only
> useful if you use the same Querys over and over. Unless I've completely
> misunderstood how it works.
>
> well the "anonymous" bindparam() still has a name. you just
On Thu, Nov 15, 2018 at 10:17 AM Martijn van Oosterhout
wrote:
>
>
>
> On Thu, 15 Nov 2018 at 14:55, Mike Bayer wrote:
>>
>> > And have all the query compilation cached. All the query stuff can be put
>> > near the model so your code isn't covered with fragments of SQLAlchemy. I
>> > have no
On Thu, 15 Nov 2018 at 14:55, Mike Bayer wrote:
> > And have all the query compilation cached. All the query stuff can be
> put near the model so your code isn't covered with fragments of SQLAlchemy.
> I have no idea if this pattern is common, but it works well for us.
>
> filter_by_id and
On Thu, Nov 15, 2018 at 12:27 AM Martijn van Oosterhout
wrote:
>
> Hoi Mike,
>
> On Wednesday, November 14, 2018 at 11:30:18 PM UTC+1, Mike Bayer wrote:
>>
>> I have some big ideas for the baked concept which may or may not
>> impact this area as well. But they are only ideas for now, I have
>>
Hoi Mike,
On Wednesday, November 14, 2018 at 11:30:18 PM UTC+1, Mike Bayer wrote:
>
> I have some big ideas for the baked concept which may or may not
> impact this area as well. But they are only ideas for now, I have
> many explicit SQLAlchemy tasks that I have to get done before I can
>
I have some big ideas for the baked concept which may or may not
impact this area as well. But they are only ideas for now, I have
many explicit SQLAlchemy tasks that I have to get done before I can
try to explore that stuff.
On Wed, Nov 14, 2018 at 4:34 PM Martijn van Oosterhout
wrote:
>
>
Hoi Mike,
You're right, we should probably measure it first. You state that the
simple joins and filters are probably cheap which I don't doubt. We also do
correlated subqueries and stuff. Actually, we also use the baking mechanism
to cache some of our own processing which goes into the
On Tue, Nov 13, 2018 at 3:49 PM Martijn van Oosterhout
wrote:
>
> Hoi,
>
> We're starting to do some pretty complicated things with the SQLAlchemy
> bakery (because we have some pretty complicated queries) and I have something
> I'd like to verify.
>
> We have queries that are constructed like
Hoi,
We're starting to do some pretty complicated things with the SQLAlchemy
bakery (because we have some pretty complicated queries) and I have
something I'd like to verify.
We have queries that are constructed like so (each letter is a step):
A B C .. M N0
A B C .. M N1
A B C .. M N2
A B C
there is a
link to a gist with the an app.py file and the library itself for you to
play with.
http://www.debrice.com/flask-sqlalchemy-caching/
I hope it helps if you're interested in caching - And sorry for the
misspellings, English ain't my mother tongue ;) .
If you have any question feel free
On Jun 1, 2010, at 1:14 AM, David wrote:
Thanks for the response, Michael. Sorry, I forgot to mention how we
are committing the data. Here is a skinned-down version of the code
that returns old data when switching between web servers.
engine = sqlalchemy.create_engine(ALCHEMY_DATABASE)
Oops, the line user_data = user.get('USERID') should have read
user_data = user_query.get('USERID')
For now, we're just going to stick with calling session.refresh
after each get. Thanks for the help.
-David
On Jun 1, 11:08 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Jun 1, 2010,
Hello,
We are having a problem that is driving us crazy. We are in a load-
balanced environment, with 2 webservers using Django+SQLAlchemy, and
one database server.
When a user is using the application, reads and writes work fine so
long as the user is on a single webserver. However, when we
On May 31, 2010, at 3:43 AM, David wrote:
Hello,
We are having a problem that is driving us crazy. We are in a load-
balanced environment, with 2 webservers using Django+SQLAlchemy, and
one database server.
When a user is using the application, reads and writes work fine so
long as
Thanks for the response, Michael. Sorry, I forgot to mention how we
are committing the data. Here is a skinned-down version of the code
that returns old data when switching between web servers.
engine = sqlalchemy.create_engine(ALCHEMY_DATABASE)
Session =
Hello,
Several people already wrote something about memcached + SqlAlchemy.
Remember, Mike Nelson wrote a mapper extention, it is available at:
http://www.ajaxlive.com/repo/mcmapper.py
http://www.ajaxlive.com/repo/mcache.py
I've rewritten it a bit to fit 0.4 release of SA.
Any response and
19 matches
Mail list logo
