CLI and parms in DB ( WAS: Re: self-intro: Craig Sebenik)

Craig craig5 at pobox.com
Mon Jul 21 06:29:25 UTC 2008


Max Kanat-Alexander wrote:
> On Fri, 18 Jul 2008 17:18:03 -0700 Craig <craig5 at pobox.com> wrote:
>> I was thinking that if combined with more CLI controls, then moving
>> away from static files becomes easier. After all, if you can still
>> edit (and view) the commands via the CLI, isn't that the same thing.
> 
> 	Well, I'm not sure we want more CLI controls, that's would add
> a fair bit of code complexity to help only a small portion of our
> users, who are the type of people who are probably already smart enough
> to just use our XML-RPC interface to create their own CLI controls.

Ok, so it's not "CLI" per se that you object to, it's supporting more 
complexity in the code. As I mentioned, *I* need a CLI so that I can 
automate all of the administrative changes. But, I have no requirement 
for how its done. It seems to me that a CLI that utilizes the XML-RPC 
layer would meet everyone's needs. Correct?


> 	But yes, a lot of those params should probably be in the DB. I
> just need a concrete example that really proves *why* that's the case.
> After all, right now, "it ain't broken."

Ok, that's resonable. The simple fact is that right now, you have to 
back up 2 different "things" for the bugzilla app: the database and the 
filesystem. The data in the DB is far more critical than the stuff in 
the filesystem. Granted losing the FS would mean any customizations 
would be lost. One problem at a time. :)

By putting all of the params data into the DB it centralizes the data. 
And since bugzilla is highly dependent on the DB anyway, moving more 
data into the DB wouldn't seem to be a major problem.

I have no idea how it would affect performance though. After looking 
around it looks like the apps need access to do some auth checking (as 
an exmaple). Which obviously means there needs to be a call into the DB 
relatively early, like maybe during "Bugzilla.pm" initialization???

I really think this is worthwhile to explore... but, it may turn out to 
be difficult to do. Or, at the very least, it could mean making a LOT fo 
changes...

Thoughts?



> I'd like to get more of the logic inside the model and out of the
> controllers. But I wouldn't want to remove it *all* and just have it
> call a single function. I want a flexible model and then the
> controllers can use it as they please.

Can you better define what you would like where? I realize that isn't 
necessarily an easy question, but if we have *some* definition of where 
to put what logic, it would be easier to start making changes.



More information about the developers mailing list