@Asset Services load should fail when field structure of an asset is out of sync with its kraken schema

[donreeal]

Hey guys,

from my observation assets do no longer work as intended when you do the following:

1. run the asset for the first time
2. change asset's field structure (e.g rename a field)
3. startup asset again

There seems to be a implicit schema for asset services that have been run at least once.
Correct me if I am wrong: an asset's schema will be published unmodifiably at first startup of the asset (baratine will not update the schema if the asset's members structure has been modified between 2 startups). That means its currently operating in a schemaful way.

Example: running a refactored asset on the same data directory

For example consider this litte asset that I've been prototyping and assume it has already been run with baratine in the default working directory (temp/baratine/.../kraken)

@Asset
public class BookServiceAsSingleAsset {

  private Map<Long, Book> books = new HashMap<>();

  public void addBook(Book book, Result<Long> result) {
    Long id = nextId();
    this.books.put(id, book);
    result.ok(id);
  }

  public void getBookById(Long id) {
    return this.books.get(id);
  } 
  // ...
}

I then changed the the name of the book field to managedBooks

@Asset
public class BookServiceAsSingleAsset {

  private Map<Long, Book> managedBooks = new HashMap<>();
  // ...
}

I then restarted baratine with the new code using the same data directory - no errors were displayed while spinning up.
Later I realized that something must be "really broken" in my application - not a single API method did respond any more. After logging out on FINEST level and doding some debugging I could see that managedBooks was null at runtime!

Proposed improvement

Well ... I've made a stupid mistake but I think those kind of mistakes are likely to happen and baratine needs some improvement here.

Of course baratine can not automatically migrate the data - nor should it overwrite the schema unasked.

But I think baratine should abort asset load with a self-explanatory runtime exception when the runtime class of an asset does not match the used kraken schema.

This would to make a possible production setting more robust and would be saving developers' time.

regards
DonReeal