1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Hi!
* So why?
I've been wondering for a long time now about all of the changes post 4.1.
I believe there is a large market of users who never wanted them, and never
cared for them. I also wanted to question the foundations of what we built.
Do uses want wrong data? How often is the query cache really valuable? If
everyone just has a root user with all privs, why carry the baggage of the
ACL code. Etc.
* What is the goal?
A micro-kernel that we then extend to add what we need (all additions come
through interfaces that can be compiled/loaded in as needed).
* So the differences?
No modes, views, triggers, stored procedures, query cache, data conversion inserts,
ACL. Less engines, less code. Assume the primary engine is transactional.
* Why now?
Why not now :)
* "This is awesome, but I need you to add back..."
Forget it. Nothing is going back in at this time. As for the future? Maybe,
but at the moment this is not the target. If you want more features, go
use MySQL.
* What platforms?
I compile on OSX, Linux (Fedora), and Solaris Express. Windows is not
supported and will stay that way unless it gets a working posix layer +
autoconf system (aka becomes a platform that is reasonable to support).
Really, get a working GNU chain going on Windows and you can get Drizzle
working on it.
Drizzle relies on a C99 compliant compiler. Please do not ask us to support
older hardware, compilers, or OS'es.
* What is the future?
Less code, more modularity, and more active involvement. A few things that
still need to be done:
- Switch to stdint
- Walk through all of the replication code
- Re-implement information schema
- Modular logging system
- ...
* "This is not a SQL compliant relational..."
Very true, and we do not aim to be that.
* What is left to be cut out?
Please ask on the mailing list or on IRC.
* Can I get involved?
Most certainly. There is plenty to do from refactoring code, design of intereface,
to documentation, etc... The best way to get involved it to join the mailing
list at:
https://launchpad.net/~drizzle-discuss/
If you wish to suggest a refactoring project or an interface please email
the mailing list and keep an open mind. Do not expect anyone will work on
your idea though, you may influence someone to do that, but more then likely
you will need to rollup your sleaves and write some code. For very simple
bits you are welcome to ask others on #drizzle on Freenode, but please be
aware that you may be asked to email the mailing list.
Showing up with a big block of code is probably the worst way of getting
your work accepted. This is unlikely to work.
Right now we use a simple captain system for commits. Anyone can send in a
proprosal for merge via launchpad but your changes may be flowed first
through someone who has been around long enough to understand code
requirements to review your code. This system is based entirely on trust,
and individuals who have shown that they can provide three good patches gain
credibility. Starting small is fine, patches that are just comments or are
event two or three line cleanups are welcome and encouraged. I would really
recommend anyone who wants to work on something start with something of this
size. Patches like these are valuable and they teach you how to work with
the system.
The general rule is no new code in the core of the server, and any changes
to interfaces need to be code line neutral. AKA if you want to add an
interface you need to be able to remove at least the number of lines of code
you added. This is a rule of thumb, and does not apply to code cleanup.
It should be pointed out that we are more focused on code style,
performance, and over all maintenance then we are features.
* What is the coding style?
Please look here:
https://blueprints.launchpad.net/drizzle/+spec/style-cleanup
If you have a question on this, please email the mailing list so that we can
clarifying the document. And when you get the answer? Please update the code
style document :)
* Should I email the mailing list with patches?
Please god no, we live in the age of the Internet :)
Create an account on launchpad.net. Create your own tree and let one of us
pull from it.
* What is the target?
Deliver a microkernel that we can use to build a database that meets the
needs of a web/cloud infrastructure. To this end we are exploring http
interfaces, sharding enhancements, etc... do not expect an Oracle, MySQL,
Postgres, or DB2. There is no GA date at the moment.
We are focusing on multi-core architecture. This is not designed to run on a
wrist watch (hint, go use SQLite). We support both 32bit and 64bit but the
class of machine we are targetting is 64bit. We are making design decisions
which assume very large amounts of RAM will be made available to the DB.
* Can I run a website with this?
No. We are stil making incompatible changes, and I certainly do not believe
the code is production quality. Right now we are defaulting many configure
operations to generate debugging code for us so our binaries are not
optimum, so do not got out and benchmark this and expect it to be one way or
the other. We are currently only doing benchmarks where it makes sense for
us to determine where bottlenecks are.
* And what is the license?
Drizzle inherits its license from MySQL's GPL. Any libraries not connected
to this are licensed under their own distribution license. All source files
are clearly idenified.
* Why drizzle?
I am from Seattle. Drizzle is our normal form of "rain" but it is not "rain",
it is drizzle. This was a bit of a rainy day project that finally found a
spot in my schedule :)
-Brian
Seattle, USA
Sun, Microsystems
|