portindex -- the second coming.

Christopher Nehren apeiron at comcast.net
Fri Oct 22 18:02:17 PDT 2004


On Fri, 2004-10-22 at 17:32 -0700, Sam Nilsson wrote:
[Please don't remove the CC on ports@ unless you believe that the
message is for the receiver only and that no one else can benefit from
it or any possible responses. I've reproduced your original message here
for archival purposes.]
> Christopher Nehren wrote:
> > You could see which ports you had installed which depended upon a
> > group of ports that matched a regex, for example (using subqueries --
> > which is one of the reasons why I'm glad that PostgreSQL was chosen,
> > instead of a certain overly popular RDBMS which shall remain nameless
> > which lacks this feature).
> 
> I agree that it is fortunate that PostgreSQL was chosen for the advanced 
> and powerful SQL features that it supports.
> 
> > If you're interested, I'd like to implement the RDBMS side of your
> > portindex replacement.
> 
> Thanks for volunteering for that. I really appreciate and all of you 
> people that do this kind of work for FreeBSD or any open source cause.
> Thank you.
> 
> While I agree that in a simple world, PostgreSQL would be a great choice 
> for RDBMS for this tool, realistically a lot of us are already 
> supporting Mysql installations for ourselves or clients or both. Many 
> times it is not a choice to switch to PostgreSQL, and for many clients 
> it is undesireable.
> 
> It would be great if this could be database agnostic. This should be 
> possible using perl's DBI, so why not? I would definately try it in that 
> case!
> 
> I'm sure you already thought of this, but I just wanted to pipe in. As a 
> potential user, this sounds great!
> 
> Thanks for volunteering and listening.
> - Sam Nilsson

Yes, DBI makes database-independent _Perl_ code possible. However, that
says nothing about the _SQL_ code (and the SQL in the Perl). One
particular portability nit is unfortunately one of the main concepts
behind the "R" part of RDBMSs: MySQL is woefully incompatible when it
comes to uniquely identifying rows in a table numerically. It uses the
auto_increment type modifier, whereas PostgreSQL for example uses
serial. More grievous incompatibilities also abound. MySQL uses
parameterised numeric types in its schema declarations, which also cause
problems. There's probably many more issues than the ones that I've
covered here, but I'll assume that you get the idea that it's not as
easy as it sounds.

Of course, there are solutions -- in the form of DBI abstractions -- to
this problem. One of the most popular is Class::DBI. Another, which I
personally favour because it doesn't force an OO mindset on the user
(which can be handy for a  utility where you'll only have one instance
of the thing represented by the DB anyway, like a utility that manages
DB-backed virtual users for an FTP server) is Alzabo. Unfortunately,
both of these abstraction layers require lots of other modules to do
their magic. It's not polite, IMO, to require a user to install
Class::DBI or Alzabo and all dependencies just to have a SQL interface
to their ports tree. 

Another possible solution is to implement one's own abstraction layer.
This isn't *too* difficult, it's good programming practise anyway, and
I've already thought of how to do it for another project that I'm
currently still designing. However, I don't have a MySQL RDBMS available
to me, and I'm far too lazy to set one up just for testing purposes.
Presuming Matthew likes the idea of the RDBMS part of portindex and of
my implementing it, I'll do my best to create portable SQL and I'll also
do my best to translate anything else to MySQL. However, I'll need
someone else to test it. Since you've spoken up about it, I'll take you
as my first volunteer. :)

And yes, you're right, I did think of this already. And don't thank me
for the idea; thank Radim for originally writing portindex and
implementing the RDBMS idea in the first place (I'll toot my own horn
here and say that I had the idea too, but never implemented it).

-- 
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".  -- Ken Thompson
-
Unix is user friendly. However, it isn't idiot friendly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20041022/62b21969/attachment.bin


More information about the freebsd-ports mailing list