Ben,
I think I might have seen you write in IRC that you had already
decided not to autoreflect after all, not sure if this is the same
person. But in any case, I wanted to say that one good reason NOT to
autoreflect is as follows. If you do the work of building a
declarative model for your database setup, it becomes very easy to
create test databases with an identical definition to your working
database, as in "just a few lines" easy. That alone is a pretty big
advantage. Another is that your declarative setup code can serve as
an additional backup of your database schema -- not that that should
matter really, but some people have projects that they leave alone for
a while, and when they come back it can be pretty hard to get
reacquainted just by looking over the table and constraint definitions
themselves, whereas reading through a sqlalchemy declarative model
that you built can make it all clear in short order.
- Eric
On Jun 6, 7:05 pm, Benjamin Hitz <h...@stanford.edu> wrote:
> Nah, I don't want a simpler interface, I want something that just generates
> the code so I can extend it as needed.
>
> Ben
> On Jun 6, 2012, at 5:57 PM, Michael Bayer wrote:
>
>
>
>
>
>
>
>
>
>
>
> > On Jun 6, 2012, at 7:47 PM, Benjamin Hitz wrote:
>
> >> This seems (to me) like an obvious question but a brief googling and
> >> looking at the docs didn't seem to find the answer.
>
> >> I have an existing database (lets say mysql)
> >> I can easily create object like:
>
> >> class BroadPeaks(Base):
> >> __table__ = Table('broad_peaks', Base.metadata, autoload=True)
>
> >> def __repr__(self):
> >> return '<Peak %r>' % (self.peak_name)
>
> >> Once I am connected, yay. And I think this has already all the
> >> relationships I need.
>
> >> But let's say I am SOOOO lazy that I just want to auto generate the lines:
>
> >> class ClassName(Base)
> >> __table__ = Table('table_name', Base.metadata, autoload=True)
>
> >> For each table. Should I just introspect the metadata object? I thought
> >> of this but not all the tables were loaded...
>
> > if you're incredibly lazy to that degree you might want to check out / help
> > out with SQLSoup, which has been with SQLAlchemy since the beginning but is
> > now it's own project:
>
> >http://readthedocs.org/docs/sqlsoup/en/latest/tutorial.html
>
> > basically you give it a name, it reflects that name and maps it. All
> > kinds of caveats apply.
>
> > --
> > 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
> > sqlalchemy+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/sqlalchemy?hl=en.
>
> --
> Ben Hitz
> Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
> Stanford University ** h...@stanford.edu
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
