Re: Testing & Map

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
>>> 
>>> 
>