On Friday 22 June 2001 13:26, barries wrote:
> On Fri, Jun 22, 2001 at 01:51:33PM -0500, Russell E Glaue wrote:
> >
> > Is it possible to build PERL into the development tree of MySQL with the
> > experimental PERL threads, and then provide an option at compile time like
> > --with-perl to include it?
> > If we put it into the development tree (and not let it go into
> > production), we can test and develop this feature a lot before a
> > thread-safe PERL is ready. At that point this feature can be released into
> > MySQL production.
>
> That's technically possible, but the UDF code would also need to be
> in the source tree.
>
> Also, you could compile it as a DSO (ie libmyperl.so) and it could be
> dynamically loaded at runtime or even lazily loaded when MySQL sees the
> first Perl code.
>
> FWIW, I was developing a trigger infrastructure that would dovetail
> nicely with UDFs and Perl, but the startup I'm working for is out of
> money and I'm having to fill my time with other projects. It was
> getting pretty close to what Monty wanted, I think: triggers with
> immeasurable performance cost unless you used them, and then a very low
> overhead. I can put a patch out for 3.23.34a (IIRC) if anyone's curious
> where they go to.
Some suggestions for people maintaining their own
patches/branches/development projects:
* use BitKeeper setup ( see
http://www.mysql.com/doc/I/n/Installing_source_tree.html )
* monitor internals list for commit messages and do bk pull frequently to
keep up with the latest developments. Note however, that you may have to wait
up to 24 hours before a change appears publically - what you pull from is
actually a clone of our real repository for security reasons and it gets
updated from cron once a day
* write test cases in mysqltest format - take a look a mysql-test/t and
mysql-test/r directories - if something is not clear, ask for help
* if you do not want your local commits announced on this list, fix up
BitKeeper/triggers/post-commit script
* if your build requires special options, take a look at the scripts in
BUILD/ and copy and hack the one that is closest to what you need
* to debug, run ./mysql-test-run --local --gdb your_testcase
If you follow the above guidelines, this will make it a lot easier for you to
keep up with MySQL development. This will also make it easier for us to
incorporate your patches if we at some point decide to do so ( and the ease
of intergration will make it more likely that we make that decision).
Here is another cool thing you can do with BitKeeper. Let's say developer A
maintains his patch and developer B maintains his, but neither is included
into our main distribution. Developer B wants to keep up with developer A
patches. All that needs to happen is for developer A to set up read access
for developer B to his repository, and then developer B can pull his changes,
which Bitkeeper will auto-merge ( or ask you to resolve if it can't in case
of conflicts).
I realize that if you already have your own setup, it might be a hassle to
convert. However, I would strongly recommend it - this will save you a lot of
time in the long run.
--
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <sasha@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
