Now I know you all read a lot of posts about this particular
subject so I'm going to try and make this as easy as possible. I'm sorry
about having to ask, but I've read everything I could possibly find on
this subject (which isn't much btw) and I'm still thoroughly confused.
Let me get the basics out of the way:
First, the reason I MUST install back-sql is because I work at
an ISP and we have a bandwidth manager (Allot) that uses LDAP Queries in
order to add users to certain pipes and whatnot. The problem is that our
user database and rate groups are maintained on a MySQL database. I am a
100% newbie when it comes to database management and basically read to
learn which is why I'm having a problem with this. If anyone knows of a
better way to go about transferring a MySQL database to BDB or a better
way to get the Allot box to make LDAP queries to a MySQL database, I'd
love to hear it.
Now on to the juicy parts. I'm running RedHat 8.0 with OpenLDAP
2.1.25. All the MyODBC drivers have been installed (current release) and
the interaction between the database and ODBC seems to be working just
fine. I loaded all the test scripts from rdbms_depend/mysql into my
MySQL database and the tables and information show up. Here's where I
get stuck because when I go to start slapd -d 5, I get this:
<<snip snip snip>>>
load_schema_map(): autoadding 'objectClass' and 'ref' mappings
load_schema_map(): error executing at_query:
Return code: -1
Native error code: 1054
SQL engine state: S0022
Message: [MySQL][ODBC 3.51 Driver][mysqld-3.23.58-Max]Unknown column
'sel_expr_u' in 'field list'
==>backsql_free_db_conn()
backsql_free_db_conn(): closing db connection
==>backsql_close_db_conn()
<==backsql_close_db_conn()
<==backsql_free_db_conn()
backsql_db_open(): connection failed, exiting
backend_startup: bi_db_open(0) failed! (1)
slapd shutdown: initiated
==>backsql_db_close()
<==backsql_db_close()
slapd shutdown: freeing system resources.
==>backsql_db_destroy()
==>backsql_free_db_env()
<==backsql_free_db_env()
==>destroy_schema_map()
==>free_oc(): 'inetOrgPerson'
==>free_attr(): 'ref'
<==free_attr()
==>free_attr(): 'objectClass'
<==free_attr()
<==free_oc()
<==destroy_schema_map()
<==backsql_db_destroy()
slapd stopped.
connections_destroy: nothing to destroy.
I saw someone post this in this mailing list elsewhere and the response
was:
"Because metadata in the test is no longer aligned with the code;
"mysql" test data is not actively maintained, basically because I had no
time to set up a mysql and test it. The only rdbms I actively etsted
and maintained is postgres. From what I infer, you don't have any sql
data to present in LDAP form, so you don't really need mysql, you can
live with postgres as well; or you can update mysql examples according
to postgres' ones (and sumbit a patch via ITS :)"
I think I recognize myself in the above writing ;)
I confirm all of the above. I had no chance (read:
time to setup mySQL and to thoroughly test back-sql)
to try it with back-sql; I usually develop it with
PostgreSQL, and sometimes make it run with BM db2
for business. I know that somebody used to use mySQL
with back-sql; I prayed those people to provide a
patch of the hacking they had to make to either the
code or the examples, but to no avail. I think you
should try the following:
- remove the examples for mySQL;
- use the examples for PostgreSQL, which are the only
ones "officially" tested (by me :); they'll surely
need some work: I don't know what support mySQL
provides for stored procedures, however, as a first
step, you may safely ignore all of them, and end
up with a read-only back-sql
- after this short step, we can figure out how to
write-enable it; only, it is very unlikely that
anyone can implement a back-sql with complete
functionality, i.e. able to write an entire
database from scratch.
- if you have more specific problems, please feel free
to ask; only, please make you include all the info
that is required to debug your problem.
If you work carefully (I suggest you use HEAD code
out of a cvs checkout, at least for the examples)
this might be the time we fix mySQL support.
p.