-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just an refresher, before proceeding with a solution for forked queries
inside Python, with what we know now is the below still a problem
requiring forking them?
Perl and Java are relatively well setup to support forked queries but
Python will require a from scratch solution, so if it's not necessary
(yet) we can avoid it for the time being.
If we go ahead I'm thinking something like a dead simple query store
object storing hashes to query names.
Queries now are defined right just as strings right in the Python code.
I'm thinking we introduce the simplest object possible, lets call it
QueryStore.
- - query = query_store.get_query("my_query_key")
- - query_store stores a hash of query keys to the queries they
represent, or a version like my_query_key_ORACLE and _POSTGRESQL if
we had to fork it.
- - Lookup version specific to the current backend and return it if found,
otherwise lookup the key directly and return it.
- - Error out if nothing is found.
- - Less work than re-implementing DataSource in a third language.
- - Could probably just leave most queries in place as they are today if
a fork is not required to minimize impact on the codebase.
Thoughts?
Devan
On Fri, 6 Feb 2009 21:19:03 +0530
Gurjeet Singh <[email protected]> wrote:
> On Fri, Feb 6, 2009 at 7:50 PM, Devan Goodwin <[email protected]>
> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Fri, 6 Feb 2009 19:37:28 +0530
> > Gurjeet Singh <[email protected]> wrote:
> >
> >
> > > >
> > > Hmm.. Although that is doable, I haven't thought about that. The
> > > way I saw it was that we'd have a IF(ORACLE) CONNECT BY ELSE
> > > IF(POSTGRES) CALL FUNCTION END kinda code...
> > >
> > > Thinking a bit, I don't see a point in porting this to Oracle! The
> > > calling syntax will be different for both the databases anyway:
> > > Oracle:
> > > select x,y from TABLE( function() );
> > > Postres:
> > > select x, y from function() as f( x int, y int).
> > >
> > > So I guess we will _have_ to keep two versions of the query at
> > > least in the python code. The other usage in PL/SQL package is
> > > anyway going to be ported over.
> > >
> > > Best regards,
> >
> > Ok this is something we'll need to be very careful with. We kinda
> > knew this was coming (having to fork queries for each database) but
> > we'll need to plan ahead for this on our end. The python queries
> > are all just variables in the source so it's probably in our best
> > interest to setup a quick framework for using one set of queries by
> > default, and allowing them to be overridden depending on your
> > database backend. I will add this to my TODO list.
> >
> > However if anything occurs to you for a way we can keep the query
> > static for both databases that would be great!
>
>
> [?] We can create a view on both DBs with different definitions and
> get away with it.. ;)
>
>
- --
Devan Goodwin <[email protected]>
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkma0KsACgkQAyHWaPV9my7cQACgttCPsysqgpSIcp2lF8L0K+8R
c+QAoKfXfaGCWEaLCmqznNACt18m0qvC
=hIKw
-----END PGP SIGNATURE-----
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
