Re: [sqlalchemy] Advice: Best practice for working with an existing database
On Apr 6, 2013, at 11:42 AM, Roberto Guerra uri...@gmail.com wrote:
+1. I prefer classical mapping also. Much cleaner. Keeps persistence and
business logic separate.
the reason I ended up not agreeing with this is because mapping applies
instrumentation to a class. Using a separate mapper means you might see this:
class MyBusinessObject(object):
pass
then elsewhere, you see some code doing this:
my_object = get_some_business_object() # my_object is a MyBusinessObject
print (my_object.first_name)
but what's first_name? That field isn't present at all on the class def for
MyBusinessObject, it was applied by mapper(). Is the fact that
my_object.first_name exists a detail of persistence or of business logic?
It's in fact both. But we don't define it twice.So the ideal of separate
persistence and business design is already out the window.
In the classic usage patterns with Hibernate, things weren't as ambiguous. In
Java, we'd always have this:
class MyBusinessObject {
public String getFirstName() {
}
public void setFirstName(String name) {
}
}
then a hibernate .xml file defines the mapping.In that case, we have a
total separation of persistence and class design.But even Hibernate moved
away from this, in modern use you'd often use JPA annotations to mark the
persistence for firstName inline.
The other enormous win with declarative is the mixin stuff. You can produce
patterns like that with mapper() as well, but not nearly as easily.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Advice: Best practice for working with an existing database
On Apr 6, 2013, at 11:42 AM, Roberto Guerra uri...@gmail.comjavascript:
wrote:
+1. I prefer classical mapping also. Much cleaner. Keeps persistence
and business logic separate.
the reason I ended up not agreeing with this is because mapping applies
instrumentation to a class. Using a separate mapper means you might see
this:
class MyBusinessObject(object):
pass
then elsewhere, you see some code doing this:
my_object = get_some_business_object() # my_object is a MyBusinessObject
print (my_object.first_name)
but what's first_name? That field isn't present at all on the class
def for MyBusinessObject, it was applied by mapper(). Is the fact that
my_object.first_name exists a detail of persistence or of business logic?
It's in fact both. But we don't define it twice.So the ideal of
separate persistence and business design is already out the window.
In the classic usage patterns with Hibernate, things weren't as ambiguous.
In Java, we'd always have this:
class MyBusinessObject {
public String getFirstName() {
}
public void setFirstName(String name) {
}
}
then a hibernate .xml file defines the mapping.In that case, we have a
total separation of persistence and class design.But even Hibernate
moved away from this, in modern use you'd often use JPA annotations to mark
the persistence for firstName inline.
The other enormous win with declarative is the mixin stuff. You can
produce patterns like that with mapper() as well, but not nearly as easily.
I preferred the old way of doing things in Hibernate. I still do it that
way when I work with Java. Sprinkling annotations in code is not a best
practice in my opinion. It ties you to a framework.
I don't really have an issue having all the field definitions in the
mapper. I just make sure I write proper doc strings. It allows me to
cleanly separate business logic from persistence details. I normally keep
all my persistence details in a separate logic that gets injected at the
boundaries if I need to do persistence. It also allows me to mix different
databases and even mix rdbms with nosql if I the need arises. I also get
the added benefit of having very fast unit tests. My tests for persistence
are separate and don't interfere if all I'm adding is a new feature or
algorithm.
Most of the time, I wrap the fields in @property anyway, so in the end the
fields do end up in the object after all. It is just an old Java habit of
mine to do that.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Advice: Best practice for working with an existing database
Hi all, I'm new to SQLAlchemy, and looking for some advice on how to approach working with an existing database. The database will not be managed by Python, and I will need to maintain whatever library I write to keep up with the occasional schema change. I am looking to write a more-or-less definitive database access layer for myself and others to use if and when we write applications in Python -- the company is not primarily a Python shop. What's my best approach for building this library? Should I use Declarative, or should I use classical mapping -- which would be better, easier to maintain, easier for others to use? Should I be writing out the classes, or should I rely on reflection? Speaking of reflection, I've been using it to analyze what SQLAlchemy thinks of the schema. For a given table created by reflection, I'm seeing _autoincrement_column, columns, foreign_keys, indexes, and primary_key -- are there other table attributes I should be inspecting? Thanks for your advice! ---Peter -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
