Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update JDBCSource #898

Merged
merged 7 commits into from
Jun 25, 2014
Merged

Update JDBCSource #898

merged 7 commits into from
Jun 25, 2014

Conversation

jcoveney
Copy link
Contributor

No description provided.

}
}
sealed trait JdbcDriver {
def driver: String
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make a class like: case class DriverName(className: String)

@jcoveney
Copy link
Contributor Author

I went a bit crazy on the typing, more as a proof of concept. @johnynek, is this how you think things should look? I suppose it is less error prone, but it also introduces a ton of cognitive overhead for a gain I'm still not decided on.

@johnynek
Copy link
Collaborator

I like it.

protected def bigint(name : String, size : Int = 20, nullable : Boolean = false) = {
mkColumnDef(name, "BIGINT", nullable, Some(size), None)
}
protected def bigint(name: ColumnName, size : Int = 20, nullable: IsNullable = NotNullable) =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't seem backward compatible. Will that be an issue?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I encouraged this, but I think that ColumnName here, might be too little win. I don't see the risk of using String directly here. The more dangerous case is: def fn(name: String, dogsName: String, teamName: String) as the compiler can't help if you get an argument wrong. Maybe one thing: it is safe to use a "raw" type, if it is the only occurrence of that type (or boxed type) in the method. Thoughts on that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me. Wish scala allowed some way of enforcing named args for methods.

@jcoveney
Copy link
Contributor Author

Ok, so I'd like to finish this... what do we think about:

  • all the bigint/int/etc methods will stay as they were
  • all of the rest of the new types will be fine, but I will add methods to accept the old signatures to be backwards compatible?

@johnynek
Copy link
Collaborator

Sounds good to me.

}

sealed abstract class ColumnType(val get: String)
private[this] case object BIGINT extends ColumnType("BIGINT")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these private? Subclasses can't use them then. Is that the intent?

@rubanm
Copy link
Contributor

rubanm commented Jun 20, 2014

Makes sense.

Jonathan Coveney added 2 commits June 24, 2014 13:40
@jcoveney
Copy link
Contributor Author

So, I removed the gratuitous typing. As is it isn't backwards compatible but I am going to argue that that is ok. It'll be pretty easy to fix but because we use overriding instead of constructors to set these values, it'll be kind of ugly to make it backwards compatible in a way that is at all meaningful.

Thoughts?

mkColumnDef(name, "BIGINT", nullable, Some(size), None)
}
protected def bigint(name: ColumnName, size: Int = 20, nullable: IsNullable = NotNullable) =
mkColumnDef(name, "DOUBLE", nullable, Some(size), None)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BIGINT changed to DOUBLE.

@johnynek
Copy link
Collaborator

looks good to me other than what looks like a typo on BIGINT.

@rubanm
Copy link
Contributor

rubanm commented Jun 25, 2014

@jcoveney Just to confirm - are you proposing fixing existing sources to work with this? Thanks.
For instance
override val columns = List(bigint("id"), varchar("value"))
to
override val columns = List(bigint(ColumnName("id")), varchar(ColumnName("value")))?

@johnynek
Copy link
Collaborator

Crap. I think Ruban's point is correct. I think the mini-dsl here we have around declaring schemas should not change. bigint("users") should be fine. I think in that call we can do the ColumnName wrapping. What else could that string mean in the case of declaring the columns?

@jcoveney
Copy link
Contributor Author

Ok, I will change that. I am proposing that the ConnectionConfig WILL have to be typed, though.

@jcoveney
Copy link
Contributor Author

Ok made it backwards compatible

@johnynek
Copy link
Collaborator

merge when green.

@jcoveney
Copy link
Contributor Author

It's green :)

johnynek added a commit that referenced this pull request Jun 25, 2014
@johnynek johnynek merged commit a56fa3d into develop Jun 25, 2014
@johnynek johnynek deleted the jco/mysql_specific_table_existence branch June 25, 2014 16:36
@rubanm
Copy link
Contributor

rubanm commented Jun 25, 2014

Cool :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants