Changes between Version 2 and Version 3 of DatabaseBackend

Timestamp:

Dec 18, 2004, 3:41:21 AM (19 years ago)

Author:

ax <trac|atIkollmIdot|org>

Comment:

added Modeling, "Store Tickets and Wiki pages directly in the Subversion repository", info-links; restructured the page

DatabaseBackend

@@ -1 +1 @@
 = Database Backend =
 
-Currently, Trac uses [http://www.sqlite.org SQLite] 
-as its database backend.
+Currently, Trac uses [http://www.sqlite.org SQLite] as its database backend.
 
-However, there has been several requests that other
-databases should be supported as well (see #126).
+However, there has been several requests that other databases should be supported as well (see #126).
 
-There has been an attempt to provide support for 
-[http://www.postgresql.org PostgreSQL]:
-source:/branches/rocky-dev/features/postgresql_support/
-though this branch is not so active this days...
+== Existing Proposals and Implementations ==
 
-=== SQLObject ===
-I think some people have been talking about using [http://sqlobject.org SQLObject] to accomplish this goal of database independence.  
+ * There has been an attempt to provide support for [http://www.postgresql.org PostgreSQL]: source:/branches/rocky-dev/features/postgresql_support/ though this branch is not so active this days...
 
-=== Data Model Changes ===
-If SQLObject works well, this proposal may not be necessary, but I would like some feedback (brad at dsource dot org) on the following proposal:  [http://trac.dsource.org/projects/test/wiki/TracTicketDataModelChanges TracTicketDataModelChanges]
+ * Data Model Change
+  If SQLObject (see below) works well, this proposal may not be necessary, but I would like some feedback (brad at dsource dot org) on the following proposal:  [http://trac.dsource.org/projects/test/wiki/TracTicketDataModelChanges TracTicketDataModelChanges]
 
-I like its elegance in handling custom fields, allowing multiple ticket attributes per ticket (i.e. this is a problem in 0.7.1, 0.8, and 0.9, so ticket gets multiple versions marked on it), and I imagine it results in reduced code overall for the app, because of the use of metadata.  
+  I like its elegance in handling custom fields, allowing multiple ticket attributes per ticket (i.e. this is a problem in 0.7.1, 0.8, and 0.9, so ticket gets multiple versions marked on it), and I imagine it results in reduced code overall for the app, because of the use of metadata.
 
+== Object-Relational Mapper ==
+
+provide a unified object interface to different RDBMS
+
+ * SQLObject
+  I think some people have been talking about using [http://sqlobject.org SQLObject] to accomplish this goal of database independence.
+
+ * [http://modeling.sourceforge.net/ Modeling]
+  Another, more advanced (and more complex) OR-Mapper.
+
+Comparisions between both and more info on Python ORMs:
+
+ * http://toulouse.amber.org/archives/2003/04/21/evaluating_objectrelational_migration.html
+ * http://google.com/search?q=SQLObject+modeling
+
+== Store Tickets and Wiki pages directly in the Subversion repository ==
+
+A compelling idea with many
+
+=== Pros ===
+
+(taken from [http://subissue.tigris.org/ Subissue], a project that aims to implement such a solution)
+
+ * "Issues are stored directly in your Subversion repository, next to your source — right where they belong!" Ie. you have access to your Issues and project documentation (Wiki) by just checking out your source.
+ * no extra RDBMS required - Subversion already has its own database
+ * "logging, intelligent reporting, history, and access control straight out of the box: most everything required for issue tracking is already in place — right down to email notification."
+
+=== Cons ===
+
+ * no SQL
+ * (from [http://projects.edgewall.com/trac/ticket/411#change_3 411]) revision numbers of the repository would climb like crazy because every ticket added or edited would create a new changeset
+ * (from [http://projects.edgewall.com/trac/ticket/411#change_3 411]) trac currently does not modify the repository at all -- changing it to do so might create other problems
+
+There seem to be more :( - the Subissue project [http://svn.haxx.se/tsvn/archive-2004-08/0473.shtml seems to be dead].
+
+== Other Alternatives ==
+
+http://wiki.w4py.org/databaseintegration.html