Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>First, db4o handles the 'simple' <a href="http://developer.db4o.com/Documentation/Reference/db4o-7.12/java/reference/html/reference/implementation_strategies/refactoring_and_schema_evolution/automatic_refactoring.html" rel="noreferrer">scenarios like adding or removing a field automatically</a>. When you adding the field, all existing object have the default value stored. When you remove a field, the data of existing object is still in the database and you can still access it. Renaming field etc are <a href="http://developer.db4o.com/Documentation/Reference/db4o-7.12/java/reference/html/reference/implementation_strategies/refactoring_and_schema_evolution/refactoring_api.html" rel="noreferrer">special 'refactoring'-calls</a>.</p> <p>Now your scenario you would do something like this:</p> <ol> <li>Remove the field 'full_name', add the new fields 'first_name' and 'second_name'</li> <li>Iterate over all 'Address'-objects</li> <li>Access the old field via the 'StoredClass'-API</li> <li>Split, change, update etc the value. Set the new values on the new field and store the object.</li> </ol> <p>Let's assume we have a 'Address'-class. The 'full_name' field has been removed. Now we wan't to copy it to the 'firstname' and 'surname'. Then it could go like this (Java):</p> <pre><code> ObjectSet&lt;Address&gt; addresses = db.query(Address.class); StoredField metaInfoOfField = db.ext().storedClass(Address.class).storedField("full_name", String.class); for (Address address : addresses) { String fullName = (String)metaInfoOfField.get(address); String[] splitName = fullName.split(" "); address.setFirstname(splitName[0]); address.setSurname(splitName[1]); db.store(address); } </code></pre> <p>As you suggested, you would write migration-code for each version-bump. It a field isn't part of your class anymore, you have to access it with 'StoredField'-API like above. </p> <p>You can get a list of all 'stored' classes with <code>ObjectContainer.ext().storedClasses()</code>. With <code>StoredClass.getStoredFields()</code> you can get a list of all store fields, no mather is the field doesn't exist anymore in your class. If a class doesn't exist anymore, you can still get the objects and access it via 'GenericObject'-class. </p> <p><strong>Update: For complexer scenarios where a database needs to migrated over multiple-version-steps.</strong></p> <p>For example it in the version v3 the address-object looks completely different. So the 'migration-script' for v1 to v2 hasn't got the fields anymore it requires (firstname and surename in my example). I think there are multiple possibilities for handling this.</p> <ol> <li>(Assuming Java for this idea. Certainly there's an equivalent in .NET). You could make the migration-step a <a href="http://groovy.codehaus.org/" rel="noreferrer">Groovy-script</a>. So each that each script does not interfere with another. Then you define 'classes' the needed classes for the migration there. So each migration has its own migration-classes. With <a href="http://developer.db4o.com/Documentation/Reference/db4o-7.12/java/reference/html/reference/implementation_strategies/aliases.html" rel="noreferrer">aliases</a> you would bind your groovy-migration-classes to the actual java-classes. </li> <li>Creating refactoring-classes for complex scenarios. Also bind this classes with <a href="http://developer.db4o.com/Documentation/Reference/db4o-7.12/java/reference/html/reference/implementation_strategies/aliases.html" rel="noreferrer">aliases</a>.</li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload