On Tue, Mar 16, 2010 at 10:29 AM, Michael Bayer
<[email protected]> wrote:
> Daniel Robbins wrote:
>
>> People want to *start* with declarative, whereas you
>> as the architect started with the core parts of the framework and
>> recently added declarative. So you know all the underpinnings, but
>> most users don't, and they want to remain on as high a level
>> (declarative) as possible without having to get sidetracked by being
>> forced to master the lower-level parts in order to simply create an
>> index for their declarative tables. Make sense? How to tie the two
>> together is not always documented clearly. Think from the new user's
>> perspective and try to accommodate them via the docs.
>
> I appreciate the rant but we're only talking about adding a distinct
> section to the declarative documentation regarding indexes, which is
> already accepted, and specific examples regarding remote_side and such are
> non-controversial as well and we shall review the cases you present.
I'm not ranting, I'm offering constructive, critical feedback for your
excellent project.
> It doesn't make much sense for the declarative documentation to completely
> duplicate the entire mapping/relation/metadata sections of the
> documentation, however.
Complete duplication is not required. However. I've written a lot of
technical documentation, and I've found that some repetition, and
building upon ideas introduced in other sections, does make technical
documentation much easier to use.
>> Index('endp_grp_ix', Endpoint.__table__.c.samplegroup_id,
>> Endpoint.__table__.c.name)
>
> Index to my knowledge does accept declarative columns these days. You can
> pass in Endpoint.samplegroup_id and Endpoint.name directly. The above
> workaround was for a bug.
Then this should be documented in the declarative section, with an example.
>> Host.interfaces = relation("HostInterface",
>> collection_class=column_mapped_collection(HostInterface.name))
>
> I'm not aware of this requirement. you should be able to create the
> "interfaces" relation inside of Host, using a string to define
> "collection_class" or otherwise use attribute_mapped_collection("name").
> If this is not possible, then its a bug.
Looks like a bug in 0.6_beta1 then:
Traceback (most recent call last):
File "base.py", line 525, in <module>
class HostInterface(Base):
File "base.py", line 533, in HostInterface
interfaces = relation('HostInterface',
collection_class=column_mapped_collection('HostInterface.name'))
File "/usr/lib64/python2.6/site-packages/sqlalchemy/orm/collections.py",
line 132, in column_mapped_collection
cols = [expression._no_literals(q) for q in util.to_list(mapping_spec)]
File "/usr/lib64/python2.6/site-packages/sqlalchemy/sql/expression.py",
line 980, in _no_literals
"to indicate a SQL expression literal, or 'literal()' to indicate
a bound value." % element)
sqlalchemy.exc.ArgumentError: Ambiguous literal: 'HostInterface.name'.
Use the 'text()' function to indicate a SQL expression literal, or
'literal()' to indicate a bound value.
Regardless, documentation in the declarative section about how to do
this cleanly would be appreciated.
> I wouldn't consider Oracle to be a good candidate for "diving in". But we
> do have a prominent sidebox in the ORM tutorial now, describing the need
> for the Sequence construct when using Firebird or Oracle, which you can
> see at
> http://www.sqlalchemy.org/docs/ormtutorial.html#define-and-create-a-table
That is a great addition.
> I'd note that the metaclass stuff you've done has been worked into a
> simple built in feature, using our new "mixin" capability, which is
> described at:
I think Mix-Ins are a great idea and very elegant, and I'm very
thankful they were added by Chris, but again in this case, more
complex examples would be extremely helpful.
If you look closely at what I am trying to do -- naming the primary
key sequence based on the name of the table -- Mix-Ins provide no
obvious mechanism to do this, since I need to create the primary key
and sequence "on the fly" after the table name is provided. With the
primary key in the base class and the table name in the sub-class,
this becomes problematic.
If you know how to implement the code I provided using a Mix-in, then
I'd love to see an example on this mailing list, or even better, in
the docs :)
Regarding Oracle, if someone only has Oracle to work with, or wants to
create an Oracle-based solution, then they need to figure out how to
do sophisticated things like this in order to get meaningful work done
with SQLAlchemy and feel comfortable with the framework. I don't think
the extra code or design philosophy of SQLAlchemy is an issue, it's
the time required to harvest the necessary info from the docs and
compile it into a working skeleton. Once the skeleton has been
assembled, SQLAlchemy is a joy to use.
> We mention prominently in the intro and on the wiki that there's a place
> for recipes like these, which is the UsageRecipes section:
>
> http://www.sqlalchemy.org/trac/wiki/UsageRecipes
>
> Recipes on that section that are of extreme general usefulness eventually
> become built in features. In particular the ManyToOne etc. idea I've
> considered, the only issue is how to present without adding to its being
> overwhelming.
OK, I can add a bunch of my code there. I wouldn't suggest that
ManyToOne be built-in to SQLAlchemy, as long as the sample code is
readily available (note: a good place to present it would be in a
declarative tutorial, to give people some customizable building blocks
to make declarative more pleasant in real-world use.)
I'm happy having my own ManyToOne as boilerplate at the top of my
SQLAlchemy code that works just the way I want it to (and can be
tweaked to work differently if I need it.) I agree with the design
philosophy of SQLAlchemy and am really only asking for beefier
examples in the docs :)
Thanks for your prompt reply and feedback.
Best Regards,
Daniel
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" 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/sqlalchemy?hl=en.
