A couple of things I found out today while working on this. First, live databases are required even if doing the initial scripts dump from the hibernate entities. Fundamental to liquibase is the notion of a change set, the first thing liquibase does is connect to the database and asks what the current change set is. Hoping we can code around this in liquibase. Second, postgres doesn’t like camelCase column names, when it sees these it faithfully creates the column, but it quotes the column name (e.g. “createdBy”). That in turn breaks the data population scripts later.
I’m going to go through all the entities and makes some updates, see what breaks. Its pretty standard in database terms to not use camelCase for column names and instead use underscores.
Here’s a section of the GatewayBean that has been updated (added name = “xx_yy” to the @Column annotations):
private String id;
private String name;
@Column(updatable=true, nullable=true, length=512)
private String description;
@Column(name = "created_by", updatable=false, nullable=false)
private String createdBy;
@Column(name = "created_on", updatable=false, nullable=false)
private Date createdOn;
@Column(name = "modified_by", updatable=true, nullable=false)
private String modifiedBy;
@Column(name = "modified_on", updatable=true, nullable=false)
private Date modifiedOn;
private GatewayType type;
private String configuration;
I FINALLY got the liquibase-maven-plugin and liquibase-hibernate working together, what a pain! Pretty cool, I think this is going to work out well. What databases do we want to support initially? We currently have an issue in one of our entities with a sequence generation scheme that isn’t compatible with Oracle, still working through that.
How about we start with:
Please have a look at https://issues.jboss.org/browse/APIMAN-452
I’m trying to ascertain the status of IPv6 support within apiman. Happy to move forward on 452, but it seems like the tip of the iceburg with regard to IPv6 support as a whole.
Hoping others know more. Also trying to build an environment here to test it.
Sometimes it's hard to know (with a project like this) what is useful
for -dev and what is useful for -user. :)
Also the -dev list hasn't really been advertised anywhere. The idea was
for it to be more "internal" - useful for core developers and
contributors only. So we figured it didn't need to be listed on the
On 6/16/2015 9:32 AM, Brandon Gaisford wrote:
> In my opinion, apiman has grown enough to warrant both a user and a dev mailing list. The current user mailbox is awesome, but lately a LOT of dev info is getting in there. How about splitting the existing mailbox and have a dedicated user and a dedicated dev mailing lists? Of course, no barrier to entry, sign up for what you want.
> apiman-user (current)
> apiman-dev (new)
> Apiman-user mailing list