Eric, I made the entity updates and also corrected some embedded SQL, everything looks good. Give it a whirl and let me know. Pull request: https://github.com/apiman/apiman/pull/146 Thanks, Brandon On Jun 17, 2015, at 4:19 PM, Brandon Gaisford <bgaisford(a)punagroup.com <mailto:bgaisford@punagroup.com>> wrote: > > 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): > > @Id > @Column(nullable=false) > privateStringid; > @Column(nullable=false) > privateStringname; > @Column(updatable=true, nullable=true, length=512) > privateStringdescription; > @Column(name ="created_by", updatable=false, nullable=false) > privateStringcreatedBy; > @Column(name ="created_on", updatable=false, nullable=false) > privateDatecreatedOn; > @Column(name ="modified_by", updatable=true, nullable=false) > privateStringmodifiedBy; > @Column(name ="modified_on", updatable=true, nullable=false) > privateDatemodifiedOn; > > @Column(updatable=true, nullable=false) > @Enumerated(EnumType.STRING) > privateGatewayTypetype; > @Lob > @Column(updatable=true, nullable=false) > privateStringconfiguration; > > > Brandon > _______________________________________________ Apiman-dev mailing list Apiman-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-dev

Makes sense. I've long lamented that I didn't spend more time naming stuff in the JPA layer. So I think this is a happy change. It's sad to learn that a live DB is needed to create the change sets. We do have access to some live DB instances (of various types) here at RH - we can check them out and use them for this purpose if necessary. The DB types we have available: DB2, sqlsrvr, mysql, oracle, postgres, sybase. And we have multiple versions of each. If live DBs are required, then obviously creating changesets may continue to be a largely manual process. -Eric

Eric, Perhaps you should start the request process now for access to those database servers. I’m targeting MySQL Server 5.1.73 and Postgres 9.3 on this side. Exact server versions probably not that important, just try and get close. Databases: apiman_current, apiman_previous, apiman_empty User: apiman Password: apiman Brandon On Jun 18, 2015, at 5:40 AM, Brandon Gaisford <bgaisford(a)punagroup.com&gt; wrote: > > My sincere hope is that the change sets used to pre-populate the database with static data is all developers will have to manage. So far so good, but the live DB requirement was a surprise. > > On Jun 18, 2015, at 3:06 AM, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: > >> Makes sense. I've long lamented that I didn't spend more time naming stuff in the JPA layer. So I think this is a happy change. >> >> It's sad to learn that a live DB is needed to create the change sets. We do have access to some live DB instances (of various types) here at RH - we can check them out and use them for this purpose if necessary. >> >> The DB types we have available: >> >> DB2, sqlsrvr, mysql, oracle, postgres, sybase. And we have multiple versions of each. >> >> If live DBs are required, then obviously creating changesets may continue to be a largely manual process. >> >> -Eric >> > > > _______________________________________________ > Apiman-dev mailing list > Apiman-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev _______________________________________________ Apiman-dev mailing list Apiman-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-dev

Yep, sounds good. I’ll include setup instructions and scripts that assume you’re starting with a fresh linux box with postgresql server and mysql server installed but not configured. Brandon On Jun 18, 2015, at 9:01 AM, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: > It's entirely self-service, so I can grab them at any time. MySQL 5.1 and Postgres 9.3 are no problem. > > Of course, these DBs are only accessible internally - so you'll have to clue me in on what to run. :) Hopefully you are automating/scripting as much as possible. :) > > -Eric > > On 6/18/2015 2:17 PM, Brandon Gaisford wrote: >> >> Eric, >> >> Perhaps you should start the request process now for access to those database servers. I’m targeting MySQL Server 5.1.73 and Postgres 9.3 on this side. Exact server versions probably not that important, just try and get close. >> >> Databases: apiman_current, apiman_previous, apiman_empty >> User: apiman >> Password: apiman >> >> Brandon >> >> On Jun 18, 2015, at 5:40 AM, Brandon Gaisford <bgaisford(a)punagroup.com&gt; wrote: >> >>> >>> My sincere hope is that the change sets used to pre-populate the database with static data is all developers will have to manage. So far so good, but the live DB requirement was a surprise. >>> >>> On Jun 18, 2015, at 3:06 AM, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: >>> >>>> Makes sense. I've long lamented that I didn't spend more time naming stuff in the JPA layer. So I think this is a happy change. >>>> >>>> It's sad to learn that a live DB is needed to create the change sets. We do have access to some live DB instances (of various types) here at RH - we can check them out and use them for this purpose if necessary. >>>> >>>> The DB types we have available: >>>> >>>> DB2, sqlsrvr, mysql, oracle, postgres, sybase. And we have multiple versions of each. >>>> >>>> If live DBs are required, then obviously creating changesets may continue to be a largely manual process. >>>> >>>> -Eric >>>> >>> >>> >>> _______________________________________________ >>> Apiman-dev mailing list >>> Apiman-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-dev >> >> >> _______________________________________________ >> Apiman-dev mailing list >> Apiman-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-dev >>