Thank you for sharing your experience, let's see, I may switch from sqlite to your H2 C++ version :-)
Best regards, Sylvain On Fri, Apr 9, 2010 at 8:15 AM, James Gregurich <[email protected]> wrote: > The key feature that attracted my attention was MVCC. Based on what I have > read, that technique is what all the big boys are using to maximize their > performance. I figured that approach would likely work well for my needs. > > I also spent time studying the source code for Firebird & Postgresql to see > if I could adapt either of them to work as an embedded db. Neither project > was coded very well. Firebird's code seemed fairly chaotic....though better > than SQLite. PostgresSQL is fairly well-written, but has an insufficient > level of abstraction. It's code is too married to the original way it was > intended to run..namely a collection of processes that communicate via IPC. > It would be a major effort to yank out all the IPC and replace it with > normal mutexes and memory management. Firebird would be easier to adapt, but > it was still not trivial because their code isn't well written. It is hard > to trace through Firebird's code and figure out how it works. Firebird needs > to be coded from scratch using modern C++ techniques. > > Finally, I'm doing commercial software with lots of proprietary IP....so > anything GPL is poison....can't use it. > > H2's code is fairly well written and structured. Its easy to follow, > understand and trace through. The license doesn't require me to make our > core intellectual property public. So, It is the best choice IMO. > > I'd say the authors of H2 should have been more disciplined when coding, > but overall, they did a good job. There tends to be a fair amount of > redundant storing of references to objects. For instance, if a subclass > needs a reference to an object and its parent already has a reference to > that object, instead of reusing the parent's reference, the subclass stores > a second reference to it. Also, there needs to be religious use of prefixes > to distinguish data members, local variables and static variables from one > another. naming variables like "newConnection" with no indication of scope > makes code harder to read and understand. Also, I prefer better > encapsulation of data members. I instruct my guys that only constructors, > destructors and accessor functions may directly reference data members...all > other member functions must go through accessors....its a little extra work > up front to write accessors, but it generally pays for itself when you need > to evolve the code later on. > > BTW: I did discover what I think is a race condition in SET EXCLUSIVE if > multithreaded mode is on. It looked to me like you could end up with two > sessions thinking they had exclusive access. However, that was in an older > version of your code. You may have fixed that by now. I don't know yet. I > just refreshed my copy of your repository today after many months. > > > On Apr 8, 2010, at 11:47 PM, Sylvain Pointeau wrote: > > > Seems interesting, could you point on the issues in sqlite3 and compare > them with H2 and how H2 solved them? > > > > Best regards, > > Sylvain > > > > -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<h2-database%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/h2-database?hl=en. > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
