Lightweight portable cross-platform client-server database - database

Is there a lightweight (in size and memory usage), portable (that i can copy and paste it to another computer without reconfiguration, or rsync it with ease), cross-platform (that runs on windows and linux, at least at data level), client-server (because there would be more than one user write at the same time, so i wont use sqlite or any other embedded database) database?
what are my options?
i don't care if it's sql or nosql, i don't care about the security too..

How about Apache Derby? It would require a JRE (Java), but other than that, it should do exactly what you want.
Alternatively, you could write a small wrapper for SQLite (or any other embedded database) and just ship that instead. Your wrapper would expose some sort of network-level API of your choosing.

Related

ODBC v Libpq: C library for PostgreSQL

I am going to be using a C library to connect and use a PostgreSQL database, I was wondering what are the pros and cons to ODBC and Libpq. From what I can tell, libpq seems to be faster but I was not able to get any clear answers or benchmarks.
Also, is there any other library that might be better then ODBC/Libpq.
ODBC is useful if you want a standard adapter that speaks a similar API for different databases. I personally think it's an awful API, but it's widely understood and well documented.
libpq talks more directly to PostgreSQL. You can get better performance with it, but probably not enough more that it'll make any difference for most apps, which spend time on query execution, network latency, etc, not in the client library.
Newer versions of psqlODBC are built on libpq and serve as an ODBC wrapper for libpq.
There's also libdbi, which offers a less ghastly API than ODBC.
For completeness, there's also the server-backend SPI, which can be used by user-defined functions written in C and loaded into the PostgreSQL server. It's not useful outside server extensions and functions.
Oh, and there's ecpg. Don't use ecpg. It's a super-legacy language-integrated-SQL tool that exists mainly for easier porting from certain other database engines. Don't use ecpg. Really.
For C++ there's the QtSQL interface (unusually for Qt, it's awful and painfully limited, don't use it) and libpq++ (OK but largely unmaintained).
Personally I write libpq code directly, but that's because I'm working on code that usually goes into PostgreSQL its self. If you can't imagine ever wanting to target anything except PostgreSQL you might want to write libpq code; otherwise probably use ODBC with psqlODBC.
ODBC is generic mostly MS Windows database access interface. Libpq is native PostgreSQL client interface. If you don't need generic interface, don't use ODBC. It is old school unfriendly designed library with high complexity. There is not any advantage against libpq.

database without operating system

Is there any database which can work without any Operating System.
My requirement is, i need to port some code on an embedded device, which runs without OS on a microcontroller. Suggest me the best database or alternate for this scenario.
I think you will implement it on an embedded system. If you write your application using C/C++ try use SQLite. There are SQLite API for C/C++
What you need is a simple key value store, is my guess. It is better you write a small package for the same as conventional databases may be too heavy for your applications.
BTW most higher end embedded systems (routers/switches) these days seem to be using sqite

Possible to build support for a filesystem directly into an application?

I am wondering if it's possible to write an application that will access a foreign filesystem, but without needing support for that filesystem from the operating system. For example, I'd like to write an app in C that runs on Mac OS X that can browse / copy files from an ext2/ext3 formatted disk. Of course, you'd have to do all the transfers through the application (not through the system using cp or the Finder), but that would be OK for my purpose. Is this possible?
There are user space libraries that allow you to access file systems.
The Linux-NTFS library (libntfs) allows you to access NTFS file systems and there are user space programs like ntfsfix to do things to the file system.
E2fsprogs does the same for ext2, ext3 and ext4 filesystems.
As Basile mentioned, Mtools is another one that provides access to FAT partitions.
There was even a program that does exactly what you're looking for on Windows. It's called ext2explore and allows you to access ext2 partitions from Windows.
It is possible. For example the GNU mtools utility are doing that (assuming a way to access the raw device or partition) for MS-DOS FAT file systems.
However, file systems inside the kernel are usually very well tested and optimized.
Yes and No. For a regular user Application is usually not possible because access to block devices is restricted to root only. Every block device should give read/write to the needed block device for that effect. This would need at best a server/client approach where a service is started on the machine and configured to give the permissions on a per block device manner.
The somewhat easier alternative would be you to use the MacFUSE implementation.
Look here:
http://code.google.com/p/macfuse/
http://groups.google.com/group/macfuse?pli=1
The MacFuse project seems no longer mantained, but can give you a starting point for your project.
The dirty and quick approach is the following as root chmod 666 /dev/diskN
You can hijack syscalls and library calls from your application and then redirect reads/writes to anything like a KV store or a distributed DB layer (using the regular calls for the "virtual devices" that you do not support).
Then, the possibilities are boundless because you don't have to reach the physical/virtual devices when someone asks for them (resolving privilege issues).

Lightweight open-source shared file system over network

We have two web servers with load balancing. We need to share some files between those servers. These would be uploaded files, session files, various files that php applications create.
We don't want to use a heavyweight, no longer maintained or a commercial solution. We're looking for some lightweight open-source software that would work as shared file system. It should be really easy to set up, must be HA available, must be very fast. It should work with RedHat Linux.
We looked at such solutions like drbd with synchronous file sharing but we can't use them because it can't work on an underlying filesystem like ext3.
OCFS may be up to snuff by now; it's worth checkout out at least. It's in the mainline linux kernel tree, http://oss.oracle.com/projects/ocfs2/ has some info on it. I've set it up before, it was pretty easy to get going.
DRBD is good for syncing over a network (direct crossover connection if at all possible), but EXT3 is not designed to be aware of changes that occur underneath it, at the block device level. For that reason you need a filesystem designed for such purposes such as the Global File System (GFS). To the best of my knowledge Red Hat has support for GFS.
The DRBD manual will give you an overview of how to use GFS with DRBD.
http://www.drbd.org/users-guide/ch-gfs.html
Don't take this as a final answer - I have not researched or used a multi-master system before, but at least this might give you something to go on.
Ideally, you would only sync the part of the data that's shared between the webservers.

Is FindFirstChangeNotification the best API to use for file system change notification on windows?

I'm new to windows programming and I'm trying to get notified of all changes to the file system (similar to the information that FileMon from SysInternals displays, but via an API). Is a FindFirstChangeNotification for each (non-network, non-substed) drive my best bet or are there other more suitable C/C++ APIs?
FindFirstChangeNotification is fine, but for slightly more ultimate power you should be using ReadDirectoryChangesW. (In fact, it's even recommended in the documentation!)
It doesn't require a function pointer, it does require you to manually decode a raw buffer, it uses Unicode file names, but it is generally better and more flexible.
On the other hand, if you want to do what FileMon does, you should probably do what FileMon does and use IFS to create and install a file system filter.
There are other ways to do it, but most of them involve effort on your part (or take performance from your app, or you have to block a thread to use them, etc). FindFirstChangeNotification is a bit complicated if you're not used to dealing with function pointers, etc, but it has the virtue of getting the OS to do the bulk of the work for you.
Actually FileSystemWatcher works perfectly with shared network drives. I am using it right now in an application which, among other things, monitors the file system for changes. (www.tabbles.net).
You can use FileSystemWatcher class. Very efficient but cannot work with Network shared drives.

Resources