Monty Taylor wrote:
Yes. That should be DRIZZLE *...
Ok. I think I have officially drug this branch down the rathole. I'm
terribly sorry for wrecking work and delaying DBD::drizzle...
Don't apologize, there is no need to. :)
Jay just sent me an email about his work in the tree today, which came
to the sensible conclusion that the changes I was committing were too
interwoven to be able to backtrack through them successfully... and he's
totally right.
Jay is going to look at starting from scratch from trunk and starting to
apply the patches one bit at a time. (I think I know where it broke, but
it's all too much atm)
I think we should/can divvy this up a bit, so we don't (and by we, this
week I seem to mean me) break each other's work.
SO, I propose these related but unrelated tasks.
Yes, small, bitesize tasks, each attached to a blueprint which can be
made dependent on each other. Create a branch for each small task,
attached to the blueprint. Merge proposals will go from small task
branch -> medium task branch -> large task branch ->trunk. I am happy
to manage the blueprint dependencies and simply assign them to you and
Patrick as you want them...I am also working on putting together a
buildbot master soon so we can start automating builds and tests.
TASK ONE: Rename mysql to drizzle OR to something more generic where it
will touch storage engines. This includes:
The above is a medium task, composed of the below small tasks...
- Replacing use of the MYSQL_TYPE_* constants to FIELD_*
- Renaming MYSQL_* types in drizzle.h to DRIZZLE_*
- Renaming MYSQL* defines to DRIZZLE*
- Changing mysql_init() to drizzle_create()
Cool. :)
- Moving my_thread_init(), my_net_init(), etc. into drizzle_create()
Excellent.
- Rename mysql_real_* to just drizzle_*
Or killing them off completely. If it smells like a hack, it probably is...
(I think I can re-do the first four bullets above pretty quickly now
that I know where it's all hanging together. I'd like someone else to
look at bullet 5 - I think it needs a different set of eyes.)
Happy to.
TASK TWO: Remove the mysys/mystrings depends from libdrizzle. The main
depends are charsets, my_malloc/my_free, some lame string manipulation
functions (and one nice one), bad header file organization and errors.
(Could conceivably be done in parallel... but probably should wait for
the above to be done and merged)
Again, this is a medium task with the following smaller tasks. What
should be decided is whether indeed this can be done in parallel or this
is dependent on the above tasks being completed. I suspect that they
can be done in parallel but in separate, smaller trees.
- Replacing my_malloc/my_free with normal malloc/free
Sure, but some places should not be a blanket replacement. I noticed a
couple places in your tree where my_multi_malloc() was replaced with
many small malloc calls, which is not efficient...perhaps for now tackle
single malloc calls. IMHO, For this tree, it is essential that valgrind
be run cleanly before any merge into another tree...
- Removing use of non-standard string functions
- Removing charset references from libdrizzle (make the lib send the
bytes the programmer sends)
Heh, these two might have to wait a bit...
- Moving some stuff around in headers (I think I did this mostly
right, so most of this can be copied verbatim)
- Removing use of MEM_ROOT in libdrizzle. This most affects
MYSQL_FIELD and MYSQL_ROWS. While we're at it, we curse the
MYSQL_ROWS implementation. (BTW Stewart - the first time I did
this, I was yearning for talloc...)
This is a medium task in itself in my opinion, even if only for
libdrizzle. Messing with MEM_ROOT is a serious undertaking. I would
recommend moving this to a separate medium task and branch.
TASK THREE: Figuring out what to do with the ER() macros and
client_errors[] (NOT RELATED TO THE ABOVE... CAN BE PARALLEL)
(I didn't do this right the first time at all)
This whole thing is a mess, as there are global static arrays that are
shared between client and server, and we generate these things with
comp_err. I'd say it's a later design issue to be solved, but it's
keeping libdrizzle tied to mysys... and it's a spiderweb anyway.
This task should be dependent on both medium task 1 and 2 (b/c of
changes to the same files in #1 and movement of header files in #2)
Once all of that is done and all still compiles and is merged, _then_ we
can tackle (instead of doing it all in one fell swoop):
- Removing references to deprecated things in client/
- Password support functions
- Unix Domain Sockets
- Shared Memory
- Embedded Server
(but keeping the command line options as null-ops for now)
Yep, medium task with subtasks all dependent on #1,2,3.
- Removing mysys/mystrings from client/
This is going to be a larger debate. ;)
- moving mysqlbinlog to a binlog dir, which will eventually also house
binlong related files from server/ for a libbinlog ... but that's a
whole other thing.
Sure.
Hopefully if we do it right, dormando and krow can continue working on
the blocking/non-blocking IO issue, and possibly krow's interest in
removing vio...
Sure.
At this point, libdrizzle can become a source package with no external
depends. and we can:
- Rearrange/split up header files and code for libdrizzle - sort of like
how libmemcached is - file for DRIZZLE_ROW, file for DRIZZLE_FIELD, etc.
Yep, this is the last major task...
Thoughts/comments? Bricks to the head? If this sounds good to you guys,
I'll transfer it to the blueprint...
Happy to help. Shall we get going? :)
-jay
Monty
Patrick Galbraith wrote:
Monty,
Now I get this error:
o -MD -MP -MF ".deps/linktest.Tpo" -c -o linktest.o linktest.c; \
then mv -f ".deps/linktest.Tpo" ".deps/linktest.Po"; else rm -f
".deps/linktest.Tpo"; exit 1; fi
linktest.c:2:25: error: mysql/mysql.h: No such file or directory
linktest.c: In function ‘main’:
linktest.c:13: error: ‘MYSQL’ undeclared (first use in this function)
linktest.c:13: error: (Each undeclared identifier is reported only once
linktest.c:13: error: for each function it appears in.)
linktest.c:13: error: expected ‘;’ before ‘my’
linktest.c:15: error: ‘my’ undeclared (first use in this function)
make[1]: *** [linktest.o] Error 1
So, linktest.c has:
nt main(int argc, char** argv) {
(void)argc;
(void)argv;
MYSQL my;
...
Shouldn't it be DRIZZLE my ?
Monty Taylor wrote:
Patrick Galbraith wrote:
Monty Taylor wrote:
I stuck a file called "linktest.c" into the libdrizzle dir to test for
missing symbols in libdrizzle while we were removing depends. Sounds
like it got removed.
Patrick Galbraith wrote:
I have all the client calls renamed to drizzle_xxx and when
compiling, get this error that doesn't tell me much:
creating libdrizzle.la
(cd .libs && rm -f libdrizzle.la && ln -s ../libdrizzle.la
libdrizzle.la)
make[1]: *** No rule to make target `linktest.o', needed by
`linktest'. Stop.
That's the only error, everything else seems to go fine. Any
thoughts? I could push this to a special tree if anyone wants to look
at it.
--Patrick
Monty,
Could you please re-commit/push ? ;)
Yes! Committing-pushing right now!
Monty
