Posts by zzzeek@fosstodon.org
(DIR) Post #ATagi91T3AI5F5cj3I by zzzeek@fosstodon.org
2023-03-14T01:21:48Z
0 likes, 0 repeats
@blacklight it sounds like your applications want some kind of global "structure of truth" that is basically a proxy to I would assume a mostly static database, where requesting data that isn't loaded uses ad-hoc connections. The Session used to have a mode called "autocommit" that was more like this, but it had problems. obv that "global" structure is not so global, different parts of the app change it inconsitently, and you are inventing your own object database essentially.
(DIR) Post #ATbG9bDZpEaau37A3c by zzzeek@fosstodon.org
2023-03-14T01:25:40Z
0 likes, 0 repeats
@blacklight im not actually kidding here, if there's a robust "global structure of truth" pattern that is worth having, someone should do it. but i have a feeling at its core it would need the objects to be fully immutable. it could use a different kind of Session that reintroduces the "autocommit" idea, loses "flush" and "transactions" entirely. as long as the lines aren't blurry which is what we used to have. blurry lines help noone
(DIR) Post #ATbfZoB2lQ31TiWXEu by zzzeek@fosstodon.org
2023-03-14T12:43:46Z
0 likes, 0 repeats
@blacklight first off it looks like you do have a notion of how ORM can work, so there's that./1
(DIR) Post #ATbostX7yNy7BD1sX2 by zzzeek@fosstodon.org
2023-03-14T12:43:58Z
0 likes, 0 repeats
@blacklight secondly, I'm sorry to say a lot of critiques of SQLAlchemy seem to come this way, where you list out a bunch of things that are completely supported, possible, and ordinary. you can set all the relationships to eager load. if you are looking for more flexible option forms rather than structural, there are wildcards for that, if the wildcards need more flexibility, that's in the area of improvements that can be made with demonstrated use cases. /2
(DIR) Post #ATbosuRqZVL417ZAwK by zzzeek@fosstodon.org
2023-03-14T13:33:13Z
0 likes, 0 repeats
@blacklight i will add that the case of parent.children[0].children[1].parent.children gets a little crazy and I think we've made some improvements to that recently. the issue is the ORM doesnt want to get into endless loops. selectinload has very new features for loading as deeply as possible until it encounters itself again, though still might not yet cover this case. it should not be surprising that eager loaders are trying to avoid loading the whole DB in as one giant graph
(DIR) Post #ATbosvpHRrg4I5XP6W by zzzeek@fosstodon.org
2023-03-14T12:46:10Z
0 likes, 0 repeats
@blacklight also lazy=joined is not a good eager loader to use for very nested eager loading. we have a loader called "selectinload" that is much better. /3
(DIR) Post #ATbosy7QvLO1Oy2vg0 by zzzeek@fosstodon.org
2023-03-14T12:47:17Z
0 likes, 0 repeats
@blacklight third, "dehydration", detached objects are plainly accessible. DetachedInstanceError only occurs when you access an attribute that was never loaded. do you want it to just return None, which is essentially the wrong answer? there's actually a loader for that called noload. But returning the wrong answer is not really SQLAlchemy's style. I thought you were going to suggest detached objects just fire up a connection and load. there's actually a way to do that too.. /4
(DIR) Post #ATbot0JCmXzWC3ZMIq by zzzeek@fosstodon.org
2023-03-14T12:57:07Z
0 likes, 0 repeats
@blacklight 5/ merge, there's of course session.merge() and helpers like merge_frozen_result() for more full-on caching usecases (see dogpile.cache example which I used in production for this kind of problem). merge() as you know in order to refresh the objects has to run a database query. so if you have a complex graph of objects, you might want to requery it more efficiently. merge() now accepts loader options too, so you can merge(object, options=[eagerloaders..])
(DIR) Post #ATbot2Ox09m8gSGyXI by zzzeek@fosstodon.org
2023-03-14T12:57:14Z
0 likes, 0 repeats
@blacklight seems like these are existing cases or areas where if improvements are needed we of course can make them, thanks for the specifics
(DIR) Post #ATbpvBhvTN1A4yjml6 by zzzeek@fosstodon.org
2023-03-14T14:39:42Z
0 likes, 0 repeats
@blacklight the "load any number of levels deep" problem is very difficult, I did tackle it in 2.0 with "recursion_depth": https://docs.sqlalchemy.org/en/20/orm/queryguide/relationships.html#sqlalchemy.orm.selectinload however it only works so far for N1->N1 relationships, not N1->N2->... it was very difficult to keep it from spinning out of control
(DIR) Post #ATm8PP8gk5fjIcS8K8 by zzzeek@fosstodon.org
2023-03-19T13:53:58Z
0 likes, 0 repeats
@blacklight briefly, the problem with merge() overall is that it's slow because it works a row at a time. it's a method taken straight from hibernate. so we've never really embraced "merge()" as a place we want to expand things, as there are better ways to "merge" things:1. SELECT all the rows you want to merge on whatever criteria. now those objects are all in the identity map.2. now merge the state you have into that list of objects you just loaded.
(DIR) Post #ATmWyUMvgjJMYQNOKW by zzzeek@fosstodon.org
2023-03-19T13:57:10Z
0 likes, 0 repeats
@blacklight that is, instead of building up a big structure of your ORM objects outside of a session first, start with the session, load everything that exists first, then build out that object graph.if you truly have the objects on the outside already, do all these same steps but then build up a dictionary on the criteria you are "merging" on. A simplistic version of this is in the very old recipe https://github.com/sqlalchemy/sqlalchemy/wiki/UniqueObject and there is also some thinking on this at https://github.com/sqlalchemy/sqlalchemy/wiki/SessionIndexing
(DIR) Post #ATmWyUwNYvfSKMxhaK by zzzeek@fosstodon.org
2023-03-19T13:57:15Z
0 likes, 0 repeats
@blacklight The other way to "merge" efficiently on "any" criteria is to use upserts; for PostgreSQL this is ON CONFLICT DO UPDATE. We have good support for this in SQLAlchemy 1.4 and even better in 2.0; you can get ORM objects back from an INSERT..ON CONFLICT..RETURNING statement.
(DIR) Post #ATmnK2dh479KBpW5q4 by zzzeek@fosstodon.org
2023-03-19T21:32:25Z
0 likes, 0 repeats
@blacklight we dont quite have a dialect-agnostic upsert right now as the way the three supporting DBs + also SQL Server and Oracle do these, they are extremely different.
(DIR) Post #AUKZnDTVsiENWJdC0O by zzzeek@fosstodon.org
2023-04-05T04:33:39Z
0 likes, 0 repeats
@simon turn them off is one way
(DIR) Post #AUPnfFNuxxnuJ2YUoy by zzzeek@fosstodon.org
2023-04-07T16:54:54Z
0 likes, 1 repeats
@simon it lies because it refers to itself in the first person, delivers answers in authoritative phrases, and all of its training data is completely secret.
(DIR) Post #AXQLNnS87UceLHxtMu by zzzeek@fosstodon.org
2023-07-06T14:39:03Z
0 likes, 0 repeats
This was one of my two posts on Threads #dogsofmastodon
(DIR) Post #AXh82MjJKpUFyEVsnY by zzzeek@fosstodon.org
2023-07-14T16:56:48Z
0 likes, 0 repeats
someone had to go to the vet today and has a condition referred towards as "limber tail syndrome" or just "broken wag" - painful! Jake should be better within a week or two #dogsofmastodon
(DIR) Post #AYQqYPTh2lz1A3N0ng by zzzeek@fosstodon.org
2023-08-05T19:29:31Z
0 likes, 0 repeats
are file paths in Python in Windows case sensitive? if so, if a user is observing this, isn't this a bug in Python? even if they are not case sensitive, what is this? why would Python do this and how do I make this user report this to Python and not us?
(DIR) Post #AYQqYQv1gdRPd7AM2i by zzzeek@fosstodon.org
2023-08-05T19:42:40Z
0 likes, 0 repeats
@fancysandwiches so..I can't freely use path methods on windows unless there is some kind of path.compare(otherpath) method, using "==" with strings breaks due to this