[sqlalchemy] Re: DynamicMetaData question
I think its more confusing for the API to break backwards-compatibility every 5 or 6 releases. Also i think adding a whole new class DelayedMetaData, which is literally just to avoid passing a flag, well i wont say insane but its a little obsessive. Agreed here. Hey list, are you confused by the current system ? Please let me know. Count me as one of the confused users. I must admit I only read through the docs quickly (but don't we all do?) and missed the mention of the threadlocal nature of the DynamicMetaData, which I thought only provided a way to delay connecting it to an engine, which was the feature I needed. the only change I would favor here would be to merge connect into MetaData, BoundMetaData and DynamicMetaData stay around for backwards compat for probably forever, and perhaps we add another method called connect_threadlocal() or something like that for people who want that behavior. i would like to have just one object that does the whole thing, now that some of the early FUD has subsided. +1 for the connect method on MetaData but I need to get at least 20 or 30 users on this list telling me how they are using metadata. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: DynamicMetaData question
On 3/14/07, JP [EMAIL PROTECTED] wrote: On Mar 13, 11:59 am, Gaetan de Menten [EMAIL PROTECTED] wrote: I only discovered (or at least understood) this thread localness of DynamicMetaData, and honestly, I don't understand in what case it can be useful. It seems like the thread localness is limited to the engine connected to the metadata. So what I'd like to understand is when anyone wouldn't want to use a global engine? As long as the connections are thread-local, we are fine, right? Not me -- I have cases where the same schema is used with two different databases by two different apps (eg, admin uses a main postgres db and public uses a local sqlite cache), so the current API does what I need, but (if I understand what you're saying) only allowing the connect string of a global engine to vary per request, rather than allowing completely different engines, would not. Yeah, I figured in the meantime that this case could cause problem. The point I have is that this case is _in my opinion_ much less common than the case where you need to delay the setup of your tables and use the DynamicMetaData for that. So I think it would have been better to have a DynamicMetaData with threadlocal=False by default. If that were the case, people would not have to connect the metadata to the engine in each and every thread. Now it's too late if we don't want to break backward compatibility but simply adding a connect method to the standard MetaData, as Michael proposed, would suit my needs just fine. Anyway, I've already rambled too much on this issue... Thanks for having taken the time to answer my question. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: DynamicMetaData question
I only discovered (or at least understood) this thread localness of DynamicMetaData, and honestly, I don't understand in what case it can be useful. It seems like the thread localness is limited to the engine connected to the metadata. So what I'd like to understand is when anyone wouldn't want to use a global engine? As long as the connections are thread-local, we are fine, right? On 3/12/07, Michael Bayer [EMAIL PROTECTED] wrote: Er well the whole point of DynamicMetaData was to replace the old ProxyEngine, which was intended to emulate SQLObject's i dont know what its called object which is what TG was using for thread-local context. Also, it doesnt entirely make sense that the threadlocal engine strategy would conflict with dynamicmetadata's thread local-ness. if you have one engine per thread, and that engine is on the tlocal strategy, it should still be doing its thing within the one thread that its used within. so feel free to try to reproduce that in a ticket or something. but also, the threadlocal engine strategy is the thing here thats kind of like, you probably dont need to be using it...its basically SA 0.1's built in behavior kind of ripped out and put over to the side, where people that really want that sort of thing can use it. but ive downplayed it a lot since then, since its kind a confusing feature if youre not the person who wrote it (or read/understood the entire source to it). whereas DynamicMetaData i think is in pretty wide usage as a thread local construct and its pretty straightfoward. the non-threadlocal use case for it is not as obvious to me. On Mar 12, 2007, at 4:58 PM, Jonathan LaCour wrote: Random question for the list, and an idea. I have an application I am working on that needs to be able to dynamically bind its metadata to an engine based upon configuration. Logically, it seems I should use `DynamicMetaData` and just call metadata.connect(engine) after I have loaded my configuration. However, I had written all of my code depending upon a threadlocal strategy as defined by using `strategy='threadlocal'` in my `create_engine` call. It turns out that DynamicMetaData has threadlocal behavior by default as well, and somehow these two things conflict. My problem was solved by making sure to pass `threadlocal=False` to my DynamicMetaData constructor. Now, here is my question: why does DynamicMetaData have any threadlocal behavior at all? It seems like the primary reason one would use a DynamicMetaData would be for being able to delay the binding of your engine to your metadata. The fact that its threadlocal is easy to miss, and I don't see why it has any threadlocal behavior at all. Am I missing something? Wouldn't it be better to two separate MetaData types, one for dynamically binding your engine, and another for threadlocal metadata? -- Jonathan LaCour http://cleverdevil.org -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: What should the future of SQLAlchemy Query look like ?
On 3/10/07, Michael Bayer [EMAIL PROTECTED] wrote: Well initial response to this post has been overwhelmingly low, but thats fine with me. After trying to tackle this today, I realized that I actually didnt want to add a brand new query object and go through a painful deprecation procedure again and all that...and I also observed that the notion of a query being against a single entity is pretty important..things like get(), load() and all that dont make much sense for multiple entities. Also, all the things Ive wanted to do are not actually that hard as we already have code to do most of it. So I did not add any new classes or modules, no new methods on session, I didnt go with my modified generative approach (its just like it always was) and changed absolutely nothing about Query thats already there (well one little thing i dont think anyone was using). But I added a whole lot of new methods to Query, essentially everything SelectResults was able to do. I was concerned about having just too much crap on Query but i think it turned out fine. Plus I added a little bit of hibernate-like capabilities to query multiple entities and extra columns too. Well, this is just Great ! I also felt those methods belonged in the core somehow. Thanks for all your work! -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] SQLAlchemy and Elixir at FOSDEM 2007
Just to let everyone who might be interested know, I'll be giving a talk about SQLAlchemy and Elixir at the FOSDEM 2007. It'll be in the python devroom. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Activemapper and multiple Foreign Keys
On 11/6/06, percious [EMAIL PROTECTED] wrote:
I think I have reached the limit of what activemapper can do for me!
Consider the following example:
class Alarm(ActiveMapper):
class mapping:
__table__ = Alarm
alarmID = column(Integer, primary_key=True)
variableAID = column(Integer, foreign_key =
'Variable.variableID')
variableBID = column(Integer, foreign_key =
'Variable.variableID')
variableA = one_to_one('CitectVariable',
colname='variableAID', backref='CitectDigitalAlarm')
Maybe it's just a typo for your example, but shouldn't that be
'Variable' instead of CitectVariable?
class Variable(ActiveMapper):
class mapping:
__table__ = Variable
variableID = column(Integer, primary_key=True)
name = column(Unicode(256))
which will produce an error something like:
class Variable(ActiveMapper):
File build\bdist.win32\egg\sqlalchemy\ext\activemapper.py, line
284, in __in
it__
File build\bdist.win32\egg\sqlalchemy\ext\activemapper.py, line
196, in proc
ess_relationships
File build\bdist.win32\egg\sqlalchemy\ext\activemapper.py, line
181, in proc
ess_relationships
File build\bdist.win32\egg\sqlalchemy\orm\mapper.py, line 607, in
add_proper
ties
File build\bdist.win32\egg\sqlalchemy\orm\mapper.py, line 619, in
add_proper
ty
File build\bdist.win32\egg\sqlalchemy\orm\mapper.py, line 671, in
_compile_p
roperty
File build\bdist.win32\egg\sqlalchemy\orm\interfaces.py, line 39,
in init
File build\bdist.win32\egg\sqlalchemy\orm\properties.py, line 190,
in do_ini
t
sqlalchemy.exceptions.ArgumentError: Error determining primary and/or
secondary
join for relationship 'variableA' between mappers 'Mapper|Alarm|Alarm'
and 'Mapp
er|Variable|Variable'. If the underlying error cannot be corrected,
you should
specify the 'primaryjoin' (and 'secondaryjoin', if there is an
association table
present) keyword arguments to the relation() function (or for
backrefs, by spec
ifying the backref using the backref() function with keyword arguments)
to expli
citly specify the join conditions. Nested error is Cant determine
join between
'Alarm' and 'Variable'; tables have more than one foreign key
constraint relati
onship between them. Please specify the 'onclause' of this join
explicitly.
Am I missing something here? I know its not great database design, but
I have what I have so I am going to have to use it.Am I going to
have to dig in and put down some bruteforce SQLAlchemy tables?
TIA
-chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboEntity announcement
Hello, Well, thank you for that. It's exactly what I needed. The funny thing here is that I've been working on developping approximately the same code for the past two or three weeks, with exactly the same syntax... And I was about to announce it in a few days (after cleaning it up and documenting it a bit)... I got a first working prototype yesterday. I've looked briefly at your code and it seems like we've taken drastically different approaches for exactly the same goal. Anyway, I'm too far in the process now to just let it go, so I'll just finish it as if I didn't know your project existed, then I'll look at what you did more thoroughly and either contribute to your project or try to convince you to switch to mine. ;-) PS: I hope I don't sound too frustrated here. Of course, I'm a bit frustrated not to have been the first here, but I am sincerely happy somebody did what I need. Greetings, Gaëtan. On 10/30/06, Daniel Haus [EMAIL PROTECTED] wrote: TurboEntity is a high-level declarative layer on top of SQLAlchemy, inspired by - but somewhat thicker than - Jonathan LaCour's ActiveMapper extension. Features currently include: - automatic polymorphic inheritance - easy specification of relationships - automatic creation of primary keys - automatic creation of foreign keys - automatic creation of secondary tables - relations can be specified across modules More information, documentation, examples and baloons for the kids can be found at http://turboentity.ematia.de/ And here's the blog post. Comments are open! http://www.danielhaus.de/2006/10/30/announcing-turboentity/ Please let me know what you think about TurboEntity and if you find it useful. Greetings, Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboEntity announcement
I'll send you a copy as soon as the basics work. For now, the system is in place but only ManyToOne work. I wanted to also implement the 3 possible types of inheritance before publishing my code, but well, now the circumstances are different... I'd be very glad if we could mix both code bases. FYI, the main difference in my code is that I don't defer classes, I only defer fields, and create them as soon as what is needed for a particular field is defined. So I had to implement a very simple dependency system... It felt like a better approach but I'm not really sure about it... Gaëtan. On 11/1/06, Daniel Haus [EMAIL PROTECTED] wrote: That's very good news, maybe we can pull together the best pieces of both approaches? I'd really like to see your solution. Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~--~~~~--~~--~--~---
