Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:58
    sqlalchemy-bot closed #7123
  • 13:58
    sqlalchemy-bot closed #6229
  • 13:58

    sqlalchemy-bot on main

    reorganize Mapped[] super outsiā€¦ implement write-only colletionsā€¦ (compare)

  • 13:44
    zzzeek demilestoned #8068
  • 13:44
    zzzeek milestoned #8068
  • 12:38
    CaselIT labeled #1093
  • 12:38
    CaselIT labeled #1093
  • 12:38
    CaselIT unlabeled #1093
  • 07:51
    jonathanherdt edited #1093
  • 07:51
    jonathanherdt edited #1093
  • 07:50
    jonathanherdt edited #1093
  • 07:50
    jonathanherdt opened #1093
  • 07:50
    jonathanherdt labeled #1093
  • Oct 05 16:47
    zzzeek milestoned #8608
  • Oct 05 16:47
    zzzeek opened #8608
  • Oct 05 16:47
    zzzeek labeled #8608
  • Oct 05 16:47
    zzzeek labeled #8608
  • Oct 05 16:06
    CaselIT labeled #8605
  • Oct 05 16:05
    CaselIT edited #8605
  • Oct 05 16:04
    CaselIT milestoned #8605
mike bayer
@zzzeek
yeah
whats the scalar value for postgresql ?
Federico Caselli
@CaselIT
mike bayer
@zzzeek
OK , we shoudl be careful on that one to not break things
im confident we have enoug test coverage
Federico Caselli
@CaselIT
I think the idea was to do a values().scalar_valued() o something like this
mike bayer
@zzzeek
yes
Federico Caselli
@CaselIT
so it should not break stuff, since it's a new thing
mike bayer
@zzzeek
OK , also that the new API makes sense, etc. havent looked in awhile
Federico Caselli
@CaselIT
basically it's so that I can remove a custom thing I have at work :)
mike bayer
@zzzeek
yes
Federico Caselli
@CaselIT
I guess another thing to look into is the cibuildwheel
since betas are nearer
also github has added support for arm osx
mike bayer
@zzzeek
I guess, I think we just have to pull the switch on that b.c. it will take effect for 1.4 at the same time
so lets just do it
Federico Caselli
@CaselIT
I think we can just do v2
let's leave 1.4 as is
since IIRC it does not support py2
mike bayer
@zzzeek
right but the release actions always come from the main branch right?
or are they broken up ?
Federico Caselli
@CaselIT
no, rel1_4 runs the 1.4 one
mike bayer
@zzzeek
oh great, we should just update now in main
Federico Caselli
@CaselIT
yes, I've it on my list
Federico Caselli
@CaselIT
@gordthompson for mssql do you have suggestion on how to make it support unicode?
Federico Caselli
@CaselIT
nevermind, I just needed to tell the compiler to translate it as nvarchar
Jonathan Vanasco
@jvanasco
@CaselIT is this for a PR or usage scenario?
Federico Caselli
@CaselIT
it was for a PR on mssql comments. but I've solved it
Jonathan Vanasco
@jvanasco
thanks. i'll look out for that on gerrit. i was working on a PR a few months ago and ran into a similar issue.
Federico Caselli
@CaselIT
I've milestoned a few issues that were without a milestone
mike bayer
@zzzeek
@CaselIT yeah I'm amazed these were hanging around
Federico Caselli
@CaselIT
I guess we forgot them
Federico Caselli
@CaselIT
mike for asyncio maybe we could add options to refresh so that if an object was loaded without relationship it could be refreshed taking into account the new options?
or should we point users to get with populate_existing=true in that case?
mike bayer
@zzzeek
i would think this has come up before is there any issue talkinga bout it?
Federico Caselli
@CaselIT
no, a question in the other gerrit
mike bayer
@zzzeek
"For more open ended "refresh" functionality,
including the ability to refresh the attributes on many objects at
once while having explicit control over relationship loader
strategies, use the
:ref:populate existing <orm_queryguide_populate_existing> feature
instead."
i think that's the current direction
Federico Caselli
@CaselIT
than I guess it has already come up
mike bayer
@zzzeek
like refresh() doesnt really do anything querying can't do. it precedes populate_existing
Federico Caselli
@CaselIT
I think it makes sense keeping it like this, so we avoid having two ways of doing the same thing
mike bayer
@zzzeek
yes if we keep adding options to refresh() then we are duplicating effort
Federico Caselli
@CaselIT
I guess the only pain of get is that you need the pk. is there an immediate way of getting the pk from an object?
mike bayer
@zzzeek
you always have to use inspect(), so to that extent it's a little inconvenient
Federico Caselli
@CaselIT
I was reading something unrelated, and it got me thinking that maybe the.index reflection query of pg is not 100% correct https://github.com/sqlalchemy/sqlalchemy/blob/a134ec1760df6295d537ff63df7aee83d957bf6a/lib/sqlalchemy/dialects/postgresql/base.py#L3957-L3995
In particular they is a subquery that has an orderby that is then aggregated in an outer query. The doubt that I have is if the subquery keeps the order or not
mike bayer
@zzzeek
@CaselIT think the order by is ignored?
Federico Caselli
@CaselIT
Yes, that's my doubt
Maybe I should switch to order by on the aggregate instead
Note that it seems that the results are always correct, but I'm not 100% sure the query is correct