Make backends more exchangable #468

Closed
oehme opened this Issue Aug 2, 2013 · 6 comments

Comments

Projects
None yet
2 participants
@oehme
Contributor

oehme commented Aug 2, 2013

I am currently introducing querydsl-sql into my project as a replacement for Mybatis. We need to do a lot of ad-hoc queries, so it suits our needs much better.

I have implemented a simple repository layer on top of querydsl so that my team members just need to inherit from a base class and get all the usual CRUD operations for free.

One thing I would like to add is in-memory repositories for testing. Currently we use Easymock to mock a repository for unit tests. But that gets tedious very quickly.

The problem is that querydsl-sql uses the column name as the path name, so querydsl-collections looks for the wrong fields. E.g. it looks for "first_name" when it should be looking for "firstName".

One way to solve this would be to add a layer on top of "Path", named "Column", e.g.:

StringColumn extends StringPath implements Column {
    ColumnMetaData metaData() {...}
}
ColumnMetaData {
    String columnName();
    ...
}

The SQL serializer and the generator would need to be changed for this. Do you see an easier way of doing this?

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Aug 2, 2013

Member

This is a good suggestion and will solve some issues in the Querydsl SQL module.

But it's a big change with backwards incompatibility.

Member

timowest commented Aug 2, 2013

This is a good suggestion and will solve some issues in the Querydsl SQL module.

But it's a big change with backwards incompatibility.

@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Aug 2, 2013

Contributor

You probably need to find out how many users actually hand-write their RelationalPath classes. If most users just generate them, it wouldn't be that much of a deal.

Contributor

oehme commented Aug 2, 2013

You probably need to find out how many users actually hand-write their RelationalPath classes. If most users just generate them, it wouldn't be that much of a deal.

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Aug 2, 2013

Member

I assume that most users use code generation. What I meant is that the semantics of the Path instances in Querydsl SQL change. Any external code that relies on the old behaviour will be broken.

So this is maybe something for 3.3.0.

Member

timowest commented Aug 2, 2013

I assume that most users use code generation. What I meant is that the semantics of the Path instances in Querydsl SQL change. Any external code that relies on the old behaviour will be broken.

So this is maybe something for 3.3.0.

@ghost ghost assigned timowest Aug 2, 2013

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Aug 5, 2013

Member

The implementation should probably also take the requirements of this ticket into account #283

Member

timowest commented Aug 5, 2013

The implementation should probably also take the requirements of this ticket into account #283

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Oct 29, 2013

Member

Now integrated via 4739193

Member

timowest commented Oct 29, 2013

Now integrated via 4739193

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Nov 17, 2013

Member

Released in 3.3.0.BETA1

Member

timowest commented Nov 17, 2013

Released in 3.3.0.BETA1

@timowest timowest closed this Nov 17, 2013

@timowest timowest added this to the 3.3.0 milestone Apr 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment