pianoman wrote:
> Jonathan, your second response work like a bomb, thanks. However,
> I did try your first proposed solution first, but iPython kept on
> complaining: type object 'Document' has no attribute 'q'. I realise
> that I'm missing something small here, like perhaps an additional
> import, and will scan through the SQLAlchemy tutorial again this
> evening to see if I can spot the problem.
Well, the SVN version of elixir currently adds this "q" property on
Entities, but I think we'll probably rename this attribute to "query"
and remove the "query" method to match up with SQLALchemy's plans for
0.4.
> I think that part of the problem for me is the fact that example
> snippets in the various tutorials and reference pages are exactly
> that - snippets - so the infrastructure required to make the various
> examples work properly, when "thrown together" is not entirely clear
> to me.
Yes, this is a big known deficiency of Elixir right now -- a lack of
good examples. We have the "videostore" TurboGears sample application
but it is woefully inadequate to show off all the great things that you
can do with Elixir and SQLAlchemy. Patches are gladly accepted :)
> And, as I mentioned in my initial question, the interplay between
> Elixir and SQLAlchemy seems somewhat shrouded in mystery to me at
> this stage. What parts are catered for by the Elixir and which by
> SQLAlchemy? Obviously, Elixir (and that's also why I used it, having
> tried SQLObject a little before) takes care of the definition/
> declaration of the objects and the database structure in a very neat
> end readable way. But one is certainly left with the idea that queries
> and selections can be tackled from Elixir too. I was rather hoping to
> keep things simple and, perhaps, do my thing mainly from the Elixir
> perspective (while my requirements are simple). But the "processing"
> power lies with SQLAlchemy, and I cannot quite figure out when I'm
> supposed to be "Elixiring" or "SQLachemying", or which imports need
> to be used at which level, or how much of the basic SQLAlchemy
> functionality is "inherited" by importing and using Elixir. (Sorry
> for this very long story - just trying to state my case as clearly as
> possible.
I totally understand your frustration, and I think we need to solve this
through improved documentation and tutorials. The long and short of
it is that Elixir is really just a thin layer on top of SQLAlchemy and
gives you two things:
1. A simpler way to define your objects, tables, and mappers all in
one simple step.
2. An extensible way to build additional functionality on top of
your own elixir "statements"
When it comes to querying, SQLAlchemy's documentation is what you really
need, along with a good understanding of what Elixir generates for you
when you create an entity. Armed with a good knowledge of your schema,
and how to access your tables (Document.table) and columns (Document.c),
you can build endlessly powerful and complex queries using SQLAlchemy's
fantastic generative query mechanism, or even its low-level select()
functionality which I directed you to.
> Anyhow, I really enjoy Elixir, and found it fairly painless to get to
> grips with it, as far as the modelling is concerned. Thanks for an
> excellent "product" - not that I'm qualified to really comment.
Anytime, and thanks for the feedback! It would be great if you could
write up a quick email with all the tips and tricks that you have
learned, and send it to the mailing list so that others can benefit. I
might even find some time to integrate it into the documentation and
tutorials at some point!
Best of luck --
--
Jonathan LaCour
http://cleverdevil.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SQLElixir" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlelixir?hl=en
-~----------~----~----~----~------~----~------~--~---
