re genericize-strategy
> 2. or could I do something with db-entity tag so that it would ref the
> defaultSchema?
I did some hacking with the cayenne-modeler-generated map.xml config file.
Unexpectedly, all of my map.xml hacks worked as expected (see below.
As best as I can tell (from “blackbox” testing - using cayenne log files to
verify), removing the [schema=“dbname”] ref results in cayenne-runtime
generating SQL-FROM with an unqualified table-name (i.e. appropriate behavior).
Then when I went further, and deleted the default schema tag, runtime still
created an unqualified FROM (i.e. appropriate behavior).
It Appears:
If the schema-refs and default-schema tags are removed from map.xml, then
cayenne-runtime relies upon the connection-url as the dbname - namespace. This
appears to be standard behavior written into cayenne.
Question:
1. is there any down-side to configuring the project absent the schema-refs (as
described in these hacks)?
2. note: cayenne-runtime seems to respond with the appropriate behavior, so my
guess is that someone designed it this way
TESTS
(all 4x tests passed)
Cayenne v4.0.1
—————————————————————————————————————————————————
original: (cayenne map.xml config with no mods)
———————————
map.xml:
<db-entity name=“table1" schema=“database1”>
cayenne runtime sql:
…
from database1.table1
hack1: (blank schema ref)
———————————
map.xml:
<property name="defaultSchema" value=“database1"/>
...
<db-entity name=“table1" schema=“”>
cayenne runtime sql:
…
from table1
hack2: (schema ref deleted)
———————————
map.xml:
<property name="defaultSchema" value=“database1"/>
...
<db-entity name=“table1">
cayenne runtime sql:
…
from table1
hack3: (schema ref & defaultSchema tag deleted)
———————————
map.xml:
<db-entity name=“table1">
cayenne runtime sql:
…
from table1
Joe
> On Jul 7, 2019, at 11:18 AM, Joe Baldwin <[email protected]> wrote:
>
> John,
>
>> https://stackoverflow.com/questions/18948418/set-database-path-in-cayenne
>
>
> Thanks for the link. I perused Andrus’ post, as well as the embedded link.
> I am not quite following your suggested strategy though …
>
> 1. As best as I can tell, the posting suggests a strategy that addresses the
> connection-url (not the multiple schema-refs in the cayenne-generated map.xml
> file)
>
> 2. Core Issue:
> - if I did not define the problem well enough, here is an example ...
> - (from log-file analysis), cayenne-runtime generates select statements
> with fully qualified table names
> - ex: "d1.t1”
> - it appears to get “d1” from the cayenne-modeler generated map.xml
> file schema-ref
> ex: "<db-entity name=“t1" schema=“d1”>”
> - there are currently about 25-30 references in the cayenne
> config files
> - changing the connection-url alone does *not* change the dbname in the
> runtime-select-statements (per log file)
> - if I just change the connection-url to another dbname,
> cayenne still uses the map.xml schema references to qualify the table names
> - so even if you specify “d0” in your connection url, cayenne
> will override and generate sql based on the scheme-ref “d1" in the map.xml
> file
> - therefore, in order to support multiple instances of my app (each
> with a separate dbname), I am forced to change all 25-30 schema-refs for
> every instance I support.
>
> 3. My goal:
> - genericize the 25-30x schema-refs to 1x schema-ref, so that I can
> deploy to multiple instances (each with its own dbname).
> - I am hoping for a DBMS-like namespace specifier (like “use dbname”)
> to change the schema-ref in one location.
>
>
> Comments:
> 1. my current strategy manual strategy is working - it is just “klunky”, and
> does not easily support CI/CD.
> 2. Just trying to find out if the (schema-namespace / single-change) strategy
> is possible - if not, I will just go with the manual strategy
>
> To Simplify:
> 1. Is there a way to specify the dbname in *one* location (like a single
> config file, or gradle param)?
> 2. or could I do something with db-entity tag so that it would ref the
> defaultSchema?
> <property name="defaultSchema" value="cmstest"/>
> so instead of
> <db-entity name=“t1" schema=“d1”>
> it might say:
> <db-entity name=“t1" schema='use-default'>
>
>
> Thanks,
> Joe
>
>
>
>
>> On Jul 6, 2019, at 10:04 PM, John Huss <[email protected]> wrote:
>>
>> https://stackoverflow.com/questions/18948418/set-database-path-in-cayenne
>>
>> On Sat, Jul 6, 2019 at 8:36 PM Joe Baldwin <[email protected]> wrote:
>>
>>> I am trying to genericize the map.xml for multiple instances with multiple
>>> dbnames (looking for a “use <dbname>” analogue for cayenne config files -
>>> or a better idea if you have one)
>>>
>>> Details ...
>>>
>>> Context:
>>> cayenne: 4.0.1
>>> db: mysql 8.0.16
>>> dbname: “cms" / “cmstest" / "cms_<bunch of others suffixes>” (all
>>> referring to the same schema)
>>>
>>> Goals:
>>> - migrate to cicd (gradle, git, jenkins, automated testing,etc)
>>> - support testing configurations, as well as multiple instances of the
>>> same app but with unique dbnames
>>>
>>> Prob:
>>> While trying to migrate to fully automated testing (using junit-5) I hit a
>>> snag:
>>> - the cayenne map.xml has the datasource name (“cms” in this instance)
>>> embedded in the map.xml config file:
>>>
>>> <property name="defaultSchema" value="cms”/>
>>> ...
>>> <db-entity name="admin" schema="cms">
>>> …
>>> </db-entity>
>>>
>>> So the general idea I had was to create a tmp-test database (cmstest), run
>>> the junit tests for unit & complex unit testing configured using gradle,
>>> then move on to a more complex testing config downstream. When I deploy
>>> it will be to multiple instances (with unique dbnames).
>>>
>>> But I cannot figure out how to genericize this map.xml so that I can
>>> easily change the datasource name - I could throw sed/awk at it - to change
>>> all the schema-name-refs, but I was hoping for something a bit more
>>> cayenne-oriented (and less brittle than sed/awk).
>>>
>>> Ideally, I am searching for a cayenne-analogue to mysql “use <dbname>” so
>>> that I could change the datasource name in one location (vs 25).
>>>
>>> Thanks
>>> Joe
>>> PS if you have any other gradle tricks that you rely on, please do send a
>>> link
>>>
>>>
>
