FAQ

Where can I download NeoDatis?

http://www.neodatis.org/downloads

How do I install NeoDatis to run with my application?

You only have to add neodatis-odb.jar to your application classpath.

Do my objects need to implement a specific NeoDatis interface to persist them?

No, there is no restriction on objects to be stored.

how can use NeoDatis in a web application (servlets) ?

To use NeoDatis in WEB application, you just need to put the odb jar in the WEB-INF/lib of the war. The default place of the odb database file (if not specified when opening the odb file) will be the execution directory of the web container. For example,if your use Tomcat, the odb file will be created in the $TOMCAT/bin directory.

Is Client/ Server mode for the DB available

Yes it is.

Have a look at the 'Using ODB as Client/Server' paragraph in the full documentation (http://www.neodatis.org/documentation). For a running example, check the class org.neodatis.odb.tutorial.Tutorial2 in the ODB Distribuition.

Do my class files must implement Serializable?

No :)

Do I need to use a database engine to run NeoDatis?

No, NeoDatis is the database engine.

Are there Import/Export mechanism in NeoDatis?

Yes. Data can be exported/imported to/from XML via API or via ODBExplorer.

It currently works only in local mode.

How should I contribute to NeoDatis?

You can contribute to NeoDatis in different ways:
(This guide has been adapted from Mylin Contributor Reference)

  • Writing feature specifications that can help you or that you guess to be important to NeoDatis
  • Posting bugs that you come across while using Neodatis
  • Mentoring: if you are an experienced user, you can support newbiews using the community channels
  • Use Forum for all of your communication. This helps committers to track the contributions.
  • Before setting out to contribute to a bug report, post on the bug report describing your intention. This helps committers guide/orient the contribution and avoids problems with patches going stale due to related work being done concurrently.
  • Post a patch to any functionality with reasonable unit test coverage
  • Creating a Patch
    • Each patch should correspond to a single bug report, and a single patch should be made for each set of changes to be reviewed.
    • Minimize the amount of changes to existing code to make review easier.
    • Synchronize often to ensure you have the latest code. Once you start modifying resources, put the Synchronize view in Outgoing mode to see your change.
    • Add an @author tag to each class that you create or make significant modification to, placed below any existing author tags and indicating the bug.
    • Ensure that there is no console output.
  • Submitting a Patch
    • Ensure there are no build errors.
    • Do not include binary files such as GIF icons in the patch, they need to be attached separately.
    • Synchronize using (Eclipse) Incoming mode and ensure that there are no conflicts, and merge them locally if there are. Right click on the project containing the changes (patches should be made for a project, not a file), press Team -> Create Patch, and make the file suffix ".txt" or ".patch".
    • Attach the patch to the bug report, and indicate in the comment what testing was done to validate it (e.g. unit test, manual tests performed).


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License