Actually there is also one other issue I ran into during release and
sometimes in CI. The new ddl project would sometimes fail to build.
Here is the build failure:
I have temporarily excluded it from the list of modules to build.
Any thoughts on that? I haven't done any googling about it yet. :)
-Eric
On 7/22/2015 12:35 PM, Brandon Gaisford wrote:
Interesting on the dates, I wonder if adding @Temporal to the entity
date fields will address the issue from the liquibase-hibernate side. I’ll add that to
the list of things to check out next round.
On Jul 22, 2015, at 3:51 AM, Eric Wittmann <eric.wittmann(a)redhat.com> wrote:
> No it really wasn't a big deal. But I'll explain what happened for the
record. There's a record, right?
>
> There were two type errors. The first was that 'timestamp' was used for all
the java.util.Date fields. Timestamp seems like a reasonable enough column type to use,
but in mysql it's quirky when you also use NOT NULL. So the DDL failed to load on
mysql because most of the date fields are also NOT NULL.
>
> Switching from 'timestamp' to 'datetime' fixed that problem. Note
that when I let hibernate populate the real mysql database, it uses 'datetime' for
the date columns. So I'm going with it. :)
>
> So now the DDL would load into mysql, but on startup hibernate failed because the
'service_defs' table had a BLOB column when it was expecting a LONGBLOB column.
After 2 mins of googling it turns out that swithing to LONGBLOB as the type in the
liquibase file solved the problem (and is supported across all DB types).
>
> So that was it!
>
> Don't worry about it - all told this part of the testing only took an hour or so.
I was working on other DB issues too. I think/hope everything should be relatively solid
now!
>
> -Eric
>
> On 7/22/2015 12:49 AM, Brandon Gaisford wrote:
>> As I’ve been thinking more about this now that I have a breath, I’m worried I
totally screwed the pooch on the latest DDLs. Geez Eric, how did the mysql ddl breakdown?
Was it a failure when executing the ddl against the database to populate it, or was it a
runtime error when using apiman?
>>
>> In either case, I feel really bad that you were stuck on this while trying to
release 1.1.5.Final. Not good.
>>
>> Let’s discuss this further tomorrow offline.
>>
>> Brandon
>>
>> On Jul 21, 2015, at 12:21 PM, Eric Wittmann <eric.wittmann(a)redhat.com>
wrote:
>>
>>> Yeah I punted the problem down the road a bit. Future Brandon and Future
Eric can deal with it. ;)
>>>
>>> -Eric
>>>
>>> On 7/21/2015 6:14 PM, Brandon Gaisford wrote:
>>>> Oh I see, got it. Well, that shifts the problem elsewhere then as those
table creates were/are generated by the liquibase-hibernate plugin. As we try and move
toward automated reconciliation of JPA entity updates within the Liquibase model, it will
be a challenge if the liquibase-hibernate plugin is generating “incorrect” liquibase table
create statements. Fun for another day… :)
>>>>
>>>> Brandon
>>>>
>>>>
>>>> On Jul 21, 2015, at 12:07 PM, Eric Wittmann
<eric.wittmann(a)redhat.com> wrote:
>>>>
>>>>> I believe the changes I made allow everything to remain database
agnostic. Here are the changes:
>>>>>
>>>>>
https://github.com/apiman/apiman/commit/c6f7dafd66a08bad7909a86c458f9ef92...
>>>>>
>>>>> According to liquibase documentation, I believe those may be the more
appropriate column types. :) I checked the postgres file and the tables seemed
reasonable to me. I haven't had a chance to give it a try. I'm hopeful.
>>>>>
>>>>> -Eric
>>>>>
>>>>> On 7/21/2015 4:10 PM, Brandon Gaisford wrote:
>>>>>> I’m glad you found some time Eric, unfortunately, I’ve been
sucked into a different issue/project that’s consuming all my free time. Regarding the
column datatype issues, that’s a bit of a concern as the Liquibase representation is
supposed to be DB agnostic. If we’re finding that we need to make type changes per
database, then I bet there is a more global way to do that. Anyway, that’s something we
can address later. I know you want to get 1.1.5.Final out, thanks for copying the DDLs
over to the overlay.
>>>>>>
>>>>>> The micro-service stuff sound cool! I’ll put my thinking cap for
automated testing strategies.
>>>>>>
>>>>>> Laters,
>>>>>>
>>>>>> Brandon
>>>>>>
>>>>>> On Jul 21, 2015, at 5:21 AM, Eric Wittmann
<eric.wittmann(a)redhat.com> wrote:
>>>>>>
>>>>>>> Update: I have finally found the time to work on the DB
stuff today. I am testing against mysql 5 and I've had to make some changes to this
file:
>>>>>>>
>>>>>>> 010-apiman-manager-api.db.tables.changelog.xml
>>>>>>>
>>>>>>> Just column datatype changes. Hopefully it won't break
postgres! But I'll let you test that out. :)
>>>>>>>
>>>>>>> For now, I'm going to use the generated DDLs to update
the current approach (basically copy/paste from ddl/target into distro-wildfly8. We'll
obviously need to evolve this more, but I want to do a 1.1.5.Final release and I would
like these new DDLs included.
>>>>>>>
>>>>>>> Also note - there are new micro-service implementations of
the apiman Manager and Gateway. These micro services are jetty based and should be easy
to extend. As a result I'm adding different servers to a new apiman repository:
>>>>>>>
>>>>>>>
https://github.com/apiman/apiman-servers
>>>>>>>
>>>>>>> There's nothing there right now but I'll be checking
in soon, at which point there will be a mysql API Manager server and an Elasticsearch API
Gateway server. These will be useful for manual testing, of course.
>>>>>>>
>>>>>>> We still need some kind of solution for more automated
testing. I'm open to ideas. :)
>>>>>>>
>>>>>>> Nice job on this liquibase stuff - it's looking pretty
good so far!
>>>>>>>
>>>>>>> -Eric
>>>>>>>
>>>>>>> On 7/15/2015 11:50 PM, Brandon Gaisford wrote:
>>>>>>>> Eric,
>>>>>>>>
>>>>>>>> I spent a couple hours this afternoon trying to update
io.apiman.manager.test.server.ManagerApiTestServer to use an external Postgres database to
run the maven tests against. I wasn’t successful and ran out of time today. I’m
currently stuck as JPA is throwing “Transaction not active” errors. I was hoping I could
get this done today and help with the testing/validation effort against the new DDLs, but
unfortunately not. Sorry dude, I tried. I’ll pick it up again tomorrow as I have time
unless you come up with a better approach.
>>>>>>>>
>>>>>>>> Laters,
>>>>>>>>
>>>>>>>> Brandon
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
_______________________________________________
Apiman-dev mailing list
Apiman-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-dev