Here's a usage example of SQLAlchemy. Particularly interesting to
SQLalchemy fans may be the AccessBroker and ContextAccess classes in
http://foss.eepatents.com/pNetworkX/browser/trunk/pnetworkx/database.py
-
pNetworkX is an enhancement to the networkx graph package that provi
try out 1166.
On Mar 17, 2006, at 6:11 PM, Florian Boesch wrote:
Michael,
I've tried on the current trunk (r1164) but it's still not working
for me.
Atached you'll find my test programm.
Cheers,
Florian
Quoting Michael Bayer <[EMAIL PROTECTED]>:
florian -
i have managed to reproduce wh
Michael,
I've tried on the current trunk (r1164) but it's still not working for me.
Atached you'll find my test programm.
Cheers,
Florian
Quoting Michael Bayer <[EMAIL PROTECTED]>:
> florian -
>
> i have managed to reproduce what is probably the problem youre
> having, and made even more modifi
hey guys -
I have committed some new stuff regarding connections/sessions into
the trunk. I got it slightly wrong yesterday, where it would hold
onto connections too long, and I believe I have fixed it today. The
only message is, dont put the trunk code on any mission critical
sites for
you can use __init__ normally, if thats the questionthe mapper decorates __init__ with its own to handle its internal accounting (which it illustrates in http://www.sqlalchemy.org/docs/adv_datamapping.myt#adv_datamapping_class ).On Mar 17, 2006, at 4:45 PM, Qvx 3000 wrote:> Is there a way to so
> Is there a way to somehow move my create_campaign() function inside> Campaign.__init__? It is not wery important, more the matter of style.
>sure you can just say:class Campaign(object):def __init__(self):self.id = Campaign.c.id.default.scalar()looks pretty stylish to me..
florian -
i have managed to reproduce what is probably the problem youre
having, and made even more modifications to inheritance to more
accurately determine join conditions, relationship directions, and
syncrules. give the trunk a try.
- mike
On Mar 17, 2006, at 10:46 AM, Florian Boesc
also here, this is possibly related to the change that you and I made
together, that when creating a relationship off an inherited mapper,
the relations are going to build off of table "b" alone, and not
table "a". if you want your relations to build off the super-mapper,
you have to be ex
On Mar 17, 2006, at 11:09 AM, Qvx 3000 wrote:
The idea is not to keep JOB_ID in dozen tables that have some work
performed on them. The reasons are that there are maybe more
different jobs that coud be performed on the table (IMPORT,
AUTOJOIN, BILLING, ...) or som of the jobs can be perf
you want "artist" to be muliple ? take off the uselist=False for
that ...
On Mar 17, 2006, at 10:40 AM, Florian Boesch wrote:
Ah works almost, it seems like the mapper gets the last in the list
of all
participants instead of the one I want.
Quoting Michael Bayer <[EMAIL PROTECTED]>:
the
at this point a fully working test program would be very
helpful...its all likely to become more unit tests.
On Mar 17, 2006, at 11:12 AM, Florian Boesch wrote:
If I ah move the mapper into the baseclass it gives yet another
participant,
still not the right one.
So to summarize:
* Mapper
I love the CASE statement, but yah I think its a cleaner in a view (also what DB's support this one ? let me guess, PG and Oracle and thats itoh and MSSQL-9.nobodyhasit :) ). You can use literal strings too for this kind of thing.if you have some brilliant notion of how this would even look
On Mar 17, 2006, at 11:57 AM, Jonathan LaCour wrote:
I think that you are going to find more and more people who want to
do things differently than this, and I think it would be a valuable
option for SQLAlchemy to support a lighter, more database-y ORM
methodology in addition to the way it
I would think that the "right thing" to do here would be to map a view containing your case, instead of kludging this into the mapper code.On 3/17/06,
Rick Morrision <[EMAIL PROTECTED]> wrote:
Hey Mike -- are there any plans for support for the CASE construct as a column type? Is anyone else inter
there is a definite change that is causing this, you can even see
where I have the other approach commented out. however, if i change
it to the other way, other code (in the zblog demo) breaks. ill try
to get the test case for this one going.
On Mar 17, 2006, at 10:46 AM, Florian Boesch
Hey Mike -- are there any plans for support for the CASE construct as a column type? Is anyone else interested in this?CASE WHEN [condition] THEN [result] [WHEN ...] [ELSE result]END
Rick
On 3/17/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
I think Aaron's simple object layer is trying to address this inpart, but it would be great if we didn't have to have two entirelydifferent object layers in SQLAlchemy. It seems more ideal to haveone basic layer that can behave either way, dep
well it seems like the approach youve taken with your application
is having somewhat of a clash with the application approach
fostered by SQLAlchemy's ORM. The general idea with the SA ORM is
that you worry about your objects and associating them together,
but you typically never need to
If I ah move the mapper into the baseclass it gives yet another participant,
still not the right one.
So to summarize:
* Mapper in base gives an incorrect participant
* Mapper in leaf class gives another incorrect participant
* Mappers for two leaves of the base give yet another incorrect parti
On 3/17/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
On Mar 17, 2006, at 8:18 AM, Qvx 3000 wrote:> 1. If I replace all those INSERTs and create_campaign with SA> objects nothing is written to database prior to calling> cc_util.process_campaign_import. The matter is even worse because I
> need ID's
Correction, this works, but I can't put such a mapper in two leaf classes of a
common super-mapper.
Quoting Florian Boesch <[EMAIL PROTECTED]>:
> Ah works almost, it seems like the mapper gets the last in the list of all
> participants instead of the one I want.
>
> Quoting Michael Bayer <[EMAIL
Was working with revision 1117 successfully. Now I updated to the downloadable
version 0.1.4 and it breaks on me at a line resmebling:
B.mapper = sqla.mapper(B, b, inherits=a)
I also tried with the current trunk, same result. Below the traceback.
Traceback (most recent call last):
File "./star
Ah works almost, it seems like the mapper gets the last in the list of all
participants instead of the one I want.
Quoting Michael Bayer <[EMAIL PROTECTED]>:
> there is !! its blank (almost) ! everyone go add something:
>
> http://www.sqlalchemy.org/trac/wiki/UsageRecipes
>
>
>
> On Mar 17,
there is !! its blank (almost) ! everyone go add something:
http://www.sqlalchemy.org/trac/wiki/UsageRecipes
On Mar 17, 2006, at 10:02 AM, Florian Boesch wrote:
Works like a charm the first try, thx a lot. Speaks for my variable-
names then
;D.
We should somewhere build a catalog o
On Mar 17, 2006, at 8:18 AM, Qvx 3000 wrote:
1. If I replace all those INSERTs and create_campaign with SA
objects nothing is written to database prior to calling
cc_util.process_campaign_import. The matter is even worse because I
need ID's for processing but they are not yet available. If
oh sorry, there is a new flag that I have not documented yet called
"correlated", you need to set that to false (although it shouldnt be
needed for this example, thats slightly buggy):
subq = users.select(order_by=[users.c.username], limit=2,
correlate=False).alias('users')
s = select(
Works like a charm the first try, thx a lot. Speaks for my variable-names then
;D.
We should somewhere build a catalog of mapper patterns or something.
Cheers,
Florian
Quoting Michael Bayer <[EMAIL PROTECTED]>:
> these would be a lot easier if you gave me a conceptual overview
> instead of my p
more on 3: I also have to explicitly convert unicode into strings (using some encoding). This is automatically handled when using SA objects.
I'm in the process of converting some of my code to use SQLAlchemy. Most natural thing was to create a class/mapper for each table. This is very convenient since I'm mostly doing selects and the ability to have most of data pulled automatically is very nice. Combined with custom properties and util
29 matches
Mail list logo