headers
Matthew Good | 1 Apr 2006 04:17

Re: Database support

On Fri, 2006-03-31 at 11:01 -0500, Sommers, Elizabeth wrote:
> Is there any chance you could put support for the firebird database into
> trac?  I am really impressed with your product, but I am trying to simplify
> things here, which means only supporting oracle and firebird.
> 
> If you can't do that - does anybody have a windows installer for psycopg? I
> can probably get away with running postgres, but I need at least a compiled
> version of the driver.  Is there a mysql driver that this project works
> with?

Windows pyscopg drivers:
http://www.stickpeople.com/projects/python/win-psycopg/index.html

One of the advantages of SQLite is that there is no server, so little
need to administer the database.  Upgrades are handled by "trac-admin",
so it's pretty easy to support.

Trac 0.10 will support MySQL, but I think that after that we should
focus on using an external library to handle the database abstraction
rather than adding more backends to Trac itself.  I've added a branch in
the Trac sandbox with initial support for SQLAlchemy[1], though I'm also
keeping an eye on SQL-API[2].

--

-- 
Matthew Good <trac@...>

[1] http://sqlalchemy.org/
[2] http://sqlobject.org/sqlapi/goals.html
Permalink | Reply | 0 comments |
headers
chongqing xiao | 1 Apr 2006 05:12
Picon

trac custom field question and suggestion

Hi,

To add custom field, the ticket_custom table is in the format of.

id
name
value

The problem with this is it makes it very difficult to write sql to
display the custom fields in any report.

My question is why not just create a ticket_custom table like this

id
customfield1 => for example, progress
customfield2 => for example, estimate_hour

this way,  it is more easy to write sql to report custom fields and it
is also more efficient.

Also, would it be ok to add a custom field just to the ticket table?
If we name the custom field with a prefix, it won't conflict with
future ticket table.
(for example, add custom_progress, custom_estimate_hour)

by the way, we just started to use Trac for our a new project, so far,
works great.

thanks/chong
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alec Thomas | 1 Apr 2006 07:30

Re: trac custom field question and suggestion

Hi,

On Fri, Mar 31, 2006 at 09:12:25PM -0600, chongqing xiao wrote:
> My question is why not just create a ticket_custom table like this
> 
> id
> customfield1 => for example, progress
> customfield2 => for example, estimate_hour

This is not scalable and, though I'm no database expert, is not
considered good database design. I assume you've seen the Wiki page on
reports involving custom fields [1]

On the upside you won't have to worry about the SQL pain for much
longer, as the reporting module is scheduled for elimination once the
query module has equivalent functionality.

> Also, would it be ok to add a custom field just to the ticket table?
> If we name the custom field with a prefix, it won't conflict with
> future ticket table.
> (for example, add custom_progress, custom_estimate_hour)

You can do this if you must, but if the schema changes in the future you
will have to manually upgrade your database. I would highly recommend
against doing this.

Alec

[1] http://projects.edgewall.com/trac/wiki/TracTicketsCustomFields#ReportsInvolvingCustomFields
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jørn A Hansen | 1 Apr 2006 10:37
Picon

Re: global trac.ini location

On 4/1/06, Brad Fuller <brad@...> wrote:
> The docs state:
>
> "The global configuration is by default localted in
> $prefix/share/trac/conf/trac.ini. It can be moved to a different
> location (for example, /etc/trac.ini), "
>
> but I don't find a global trac.ini anywhere. Is it created on the fly?
> And if so, is it easy to change what it generates?

I don't think it's created for you at all. I just created it myself
containing only the configuration parameters I wanted globally.

Maybe the docs could be more clear about this.  Since the docs are
wiki pages you are welcome to fix this at the trac project site.

-- JornH
> _______________________________________________
> Trac mailing list
> Trac@...
> http://lists.edgewall.com/mailman/listinfo/trac
>
Permalink | Reply | 4 comments |
headers
chongqing xiao | 1 Apr 2006 18:44
Picon

Re: trac custom field question and suggestion

Hi, Alec:

What do mean it is not a good database design.

table ticket_custom (ticket_id, progress, estimate) is a standard
relational table.

In fact, I think the way the current ticket_custom (id, name ,value)
won't be scalable.
(For example, if you have two custom field, to include them in the
report, you need
to do left out join twice and both left out join has to check both id
and value of (name) column.

if the table is like (ticket_id, progress, estimate), it will be one
left join with (ticketid)  no matter how many custom fields you have.

Also, using (id, name, value), you have no way to specify the data
type for each custom field.

Could anyone in the core team to comment on what is the reason to use
(id,name,value)
schema?

I checked the code, it seems it should be pretty easy to make
ticket_custom works the same as standard ticket table.

thanks
chong
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alec Thomas | 1 Apr 2006 19:06

Re: trac custom field question and suggestion

On Sat, Apr 01, 2006 at 10:44:56AM -0600, chongqing xiao wrote:
> Hi, Alec:
> 
> What do mean it is not a good database design.
> table ticket_custom (ticket_id, progress, estimate) is a standard
> relational table.
> In fact, I think the way the current ticket_custom (id, name ,value)
> won't be scalable.

What I meant by not being scalable is that Trac allows the user to
define any number of custom fields. How are you going to cater for that
with this table? It has 'progress' and 'estimate', what if a user wants
'testers', or 'customers', etc.

I assume you are proposing that the table be altered as users add/remove
custom fields? That is what I was referring to when I said bad database
design; updating your schema based on user configurable values. It seems
to me that your schema should not be modifiable on the fly by users.

> (For example, if you have two custom field, to include them in the
> report, you need
> to do left out join twice and both left out join has to check both id
> and value of (name) column.
> 
> if the table is like (ticket_id, progress, estimate), it will be one
> left join with (ticketid)  no matter how many custom fields you have.
> 
> Also, using (id, name, value), you have no way to specify the data
> type for each custom field.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
chongqing xiao | 1 Apr 2006 21:15
Picon

Re: trac custom field question and suggestion

I see your point, but why not let the customer change the schma of
ticket_custom?
It is a custom owned table any way.

It won't be a problem for updating to new version of trac.
It makes writing custom report with custom fields more easy and it is
also more efficient.
Also, the code to handle it would be very similar to how the (ticket)
table is handled and should be very simple.

Anyhow, I would love to help out with this change but it will great if
anyone in the core team can comment on whether this is something will
be considered?

thanks
chong

On 4/1/06, Alec Thomas <trac-list@...> wrote:
> On Sat, Apr 01, 2006 at 10:44:56AM -0600, chongqing xiao wrote:
> > Hi, Alec:
> >
> > What do mean it is not a good database design.
> > table ticket_custom (ticket_id, progress, estimate) is a standard
> > relational table.
> > In fact, I think the way the current ticket_custom (id, name ,value)
> > won't be scalable.
>
> What I meant by not being scalable is that Trac allows the user to
> define any number of custom fields. How are you going to cater for that
> with this table? It has 'progress' and 'estimate', what if a user wants
(Continue reading)

Permalink | Reply | 2 comments |
headers
Aaron Turner | 1 Apr 2006 22:48
Picon

Re: dyld: Symbol not found: _apr_sockaddr_port_get

Jérôme Lebel <jeromelebel <at> ...> writes:

[snip]

> dyld: lazy symbol binding failed: Symbol not found:  
> _apr_sockaddr_port_get
>    Referenced from: /opt/local/apache2/modules/mod_python.so
>    Expected in: flat namespace
> 
> dyld: Symbol not found: _apr_sockaddr_port_get
>    Referenced from: /opt/local/apache2/modules/mod_python.so
>    Expected in: flat namespace
> 
> [Tue Mar 28 15:26:19 2006] [notice] child pid 7304 exit signal Trace/ 
> BPT trap (5)

Hey Jerome,
Looks like I'm having the exact same problem as you (also using darwinports).  
I've tried rebuilding apache2, apr, apr-utils and mod_python with no luck, and
figured I'd ask if you ever figured it out.

Thanks,
Aaron
Permalink | Reply | 2 comments |
headers
Cory Omand | 1 Apr 2006 23:08

Re: Re: dyld: Symbol not found: _apr_sockaddr_port_get

On 4/1/06, Aaron Turner <synfinatic@...> wrote:
> Jérôme Lebel <jeromelebel <at> ...> writes:
>
> [snip]
>
> > dyld: lazy symbol binding failed: Symbol not found:
> > _apr_sockaddr_port_get
> >    Referenced from: /opt/local/apache2/modules/mod_python.so
> >    Expected in: flat namespace
> >
> > dyld: Symbol not found: _apr_sockaddr_port_get
> >    Referenced from: /opt/local/apache2/modules/mod_python.so
> >    Expected in: flat namespace
> >
> > [Tue Mar 28 15:26:19 2006] [notice] child pid 7304 exit signal Trace/
> > BPT trap (5)
>
> Hey Jerome,
> Looks like I'm having the exact same problem as you (also using darwinports).
> I've tried rebuilding apache2, apr, apr-utils and mod_python with no luck, and
> figured I'd ask if you ever figured it out.

I assume that you're using APR/APU 1.2.2 -- apr_sockaddr_port_get
disappeared between the 0.9.x series and 1.2.x.  I found a patch for
mod_python 3.2.8 which I've used successfully on several trac
installations.  You can grab my sanitized version of the patch here:

http://svn.blastwave.org/browser/csw/trunk/server/mod_python/files/apr.diff?format=raw

Regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robin Bowes | 1 Apr 2006 23:17
Favicon

DIfferent permissions for home page?

Hi,

Is it, or would it be, possible to have different permissions for the
"home" page for a trac project?

Let me explain better...

I'd like to give access for certain logins to just the ticketing and
report viewing modules. If I do this they see an error message when they
hit the fromt page about wiki_view permissions. So, I have to give them
wiki view permissions as well.

Would it be possible to treat the "home" page differently than the rest
of the wiki so users are allowed to view the home page but not the rest
of the wiki?

Thanks,

R.
Permalink | Reply | 3 comments |

Gmane