decorators and mapping

[davidmoshal]

Hi, just evaluating this project, and wondering if there is a way to simply persist Typescript objects, with zero, or minimal, mapping, e.g: an @entity decorator an a class, even if it means being limited to some subset of databases (e.g Sqlite) ?

[davidmoshal]

found this file: src/decorators/Mapping.ts but no examples of using it.
tried this without success:

import { entity, primary, index, field } from "wetland/dist/src/decorators/Mapping"

@entity()
export class User{
  @index('id') id:number
  @field('username', {type: 'string', length: 255})
  username: string;
}

would be nice to have to only provide the bare minimum to get a Typescript class persisted, e.g:

import { entity, primary, index, field } from "wetland/dist/src/decorators/Mapping"

@entity
@id
export class User{
  username: string;
  address:Array<Address>;
}

@entity
@id
export class Address{
}

[RWOverdijk]

Hello @davidmoshal,

I'm not sure what a "typescript object" is. I assume you mean object literal? Or just a class?

The decorators haven't been finished yet, but they're super easy to build. We first wanted to make sure the implementations works for es6, and make sure that the ORM itself is stable. Decorators are simple calls to the mapping methods, that are all on the mapping instance.

If you feel like helping out with that, I'd be more than happy to tell you how to write them, it's super easy. Otherwise they'll be added soon, so I hope you can wait for them.

But yes, the way to use them is almost as you described them.

import { entity, primary, index, field } from "wetland";

@entity()
export class User{
  @index() 
  @generatedValue('autoIncrement')
  id:number // 'id' wasn't needed

  @field({type: 'string', length: 255}) // 'username' was't needed
  username: string;
}

If you feel like helping out, drop me a message on gitter :) https://gitter.im/RWOverdijk

[RWOverdijk]

As to some background information, the idea was to support ES6 and Typescript out of the box. It's super easy to build decorators, and less easy to build an elegant format for ES6. That's why we started with ES6 support. Now, pretty much any decorator is a simple call to mapping instances (like you found in the file).

[davidmoshal]

@RWOverdijk that's great news.

I'm not sure what a "typescript object" is. I assume you mean object literal? Or just a class?

I was referring to a Typescript class. However, thinking about that, any Typescript Interface or Type probably could be included in that category. Object literals might be pushing it (but maybe not).

My example above uses decorators from Java's JPA, that's pretty much all I use with the ObjectDB database - somewhat undermarketed, but a superb product that I've used for over 10 years in production with zero problems, worth looking at BTW. Actually it supports JDO as well as JPA. Easily the fastest Java database there is. Both JDO and JPA have decorators which might help you think about how to design yours. In the Java world they are called 'Annotations'. Here is a comparison of JDO vs JPA.

Re helping out, would love to, but... after posting above I discovered the TypeORM project which worked first time out the box for me.

Interestingly it takes the opposite approach, it's written in Typescript, then transpiled to ES6.
You might want to look into doing it that way.

Dave

[RWOverdijk]

@davidmoshal I appreciate your input, but I am aware of annotations, as well as JPA. I've read the spec three times before starting this module. All 570 boring pages of it. :)

This is based on the spec, and the implementations of Doctrine 2 and Hibernate.

On top of that, this project is also written with typescript and then transpiled to ES6... So I'm not sure what I'm missing.

Closing this now.

[davidmoshal]

Sorry, yes, I forgot that :) it's in TS.

Re what's missing:

1. documentation and examples on how to use decorators.

2. Maximal use of defaults so that classes can be persisted with minimal decoration. The only annotations I've ever used with objectdb are @entity and @id. Even these are optional with their jdo api ! So not sure why there can't be a default which annotates all fields including default mapping of arrays and associated entities.

[RWOverdijk]

@davidmoshal

1. That's a very fair point. We're working on that, now that the api is finally stable. Decorators are up soon, but the majority of users don't use typescript, so it's lower on the list.
2. Because that kills your declarative entities and in my book is an anti-pattern. Setting up defaults is simple, it's not in there by design. Now, if you need properties that don't map to columns you can. It makes automated migrations slicker and more accurate and a lot more advantages come with it. I understand your opinion and preference (I've been there, it does have its charm) but I personally disagree.

Any more ideas or feedback, feel free to share them. In any case, I'm glad you found the project you were looking for.