It's going to take some time...

[Paladin]

...to wrap my head around the database interaction classes. I mean,
two separate classes for writing queries (SQLPhobia?) plus separate
classes for tables and so on?

Is there a rationale for this written down somewhere? I'm not saying
it's wrong, or deficient, or anything else like that. I'm just saying
this is *so* far removed from anything I would have ever considered
implementing I'm going to need some more information and pointers
before i can catch up with it. It's like presenting someone with an
RPN calculator without explaining what RPN is. (Yes, I have a HP RPN
calculator, on my desk.)

From what I can tell (correct me if I'm wrong) classes JTable and
JTableNested taken together are incarnations of what I'd term a model,
extended for, it appears, some but not all of the tables in the
database. (Other tables are interacted with directly by other classes
in Joomla; what the reason is for this distinction I don't readily
comprehend.)

The two Query classes seem only to exist to provide a more convoluted
way of generating SQL. I really don't see the reason they exist,
considering you pretty much need to know how to write SQL to use them
correctly in the first place, though perhaps I'm missing something
here; if so please enlighten me.

Then there's some elaborate database classes, locking Joomla into
mysql.

I think I grasp the "what" of it in a vague outline sort of way, but
I'd appreciate being pointed to something that might fill in the
"why?" blanks, so I can no longer feel like I'm translating from a
dictionary when I look at it.

[Joseph LeBlanc]

I can't speak to JTableNested as that's a new one for me. JTable is designed to work with a single table so that you don't have to write INSERT and UPDATE statements. It's a partial implementation of the Active Record pattern: http://en.wikipedia.org/wiki/Active_record_pattern You shouldn't see many INSERT or UPDATE statements in components, plugins, or modules. If you do, it's either a query waiting to be rewritten with JTable or it's working with a table that doesn't have an autoincrement primary key.

AFAIK, the query classes are there so that a) Joomla can be ported to other DBs in the future b) queries for things like pagination can be generated more easily.

-Joe

[Paladin]

On Nov 23, 9:35 am, Joseph LeBlanc <cont...@jlleblanc.com> wrote:
> AFAIK, the query classes are there so that a) Joomla can be ported to other DBs in the future b) queries for things like pagination can be generated more easily.

Thank you for the answer, Joe. I don't yet know enough to speak
meaningfully about point #b, but I don't see how it accomplishes point
#a at all.

This is probably too late to matter, but doing query objects first
seems like it's the wrong way round if the goal is db portability. I
would have thought implementing PDO or something (anything!) similar
would have been first steps, sending the usual SQL queries to that,
and only *after* that is working start worrying about divergences from
normal SQL (which to my mind is the only reason for going in the
direction of query objects) and how to interface with the db layer.
(Implicit in this is the assumption that it's a waste of time and
energy for Joomla to build its own db transparency layer. Other people
get paid to do that, and doing it is *their* prime function, not
Joomla's, so we should leverage their work, rather than arrogantly
assume we can do their job for their db better than they can. We can
climb farther if we start by standing on their shoulders.) That way,
db portability for a large set of db's that use standard SQL gets
accomplished quickly, and the non-standard dbs are added later, after
the exceptions are known. It seems to me that until you know where the
exceptions are (which can only be found reliably by experimentation)
you can't begin to know what kind of special handling you'll need to
give query processing, and without that knowledge, any decisions made
about query processing are bound to be suboptimal.

The query methods contain no divergences from SQL, and significantly,
no provision for knowing where or if they must diverge, so the plan
must be to treat them as base objects, and extend them as necessary
for each db. Right? (Are there really that many dbs that diverge from
the SQL standard so much that this sort of elaborate structure is
necessary? It just seems like overkill in an already complex system to
build a class structure for which little if any need has been
demonstrated.)

I confess I've not been as deep in this for as long as most of you, so
I could be missing the point completely, but this seems to me like an
example of YAGNI (You Ain't Gonna Need It).

(In case you haven't noticed, I have a strong bias towards simplicity.
Complex systems designed as complex systems always fail, the more
complex the system the larger percentage of its time is spent in
failure mode instead of useful work. Successful complex systems were
designed as simple systems and grew to be complex. Reducing complexity
in systems increases their maintainability and usable life span;
increasing complexity almost always decreases both. I say "almost"
because there may possibly exist exceptions to that rule, but none
come to mind.)

[Andrew Eddie]

Hi Arlen.

JDatabase is just an abstraction layer for providing database engine
connectivity. It was originally done at the behest of "why can't we
run on Postgres" and once completed, those people failed to deliver.
Maybe one day we will get to cross-platform nirvana, but for now
JDatabase is useful for creating secondary connectors to other
business systems. I've certainly used MSSQL (painful as it is) and
Omar has done one for Oracle.

There is no reason why JDatabase couldn't do PDO in the future. This
is something I'd support and I don't think this would be particularly
difficult to refactor.

JTable is an abstraction layer for object CRUD. Yes, it's a model at
the data object level. It has become quite sophisticated over the
years particularly with regard to automatically handling access
control assets now.

Ideally it's successor would be something along the Doctrine flavour
but at least in the 1.x series (<enum>, which is why I don't think
it's a good idea to change to 2.0 now </rant>), it's the best we've
got and honestly I think it serves us well (well enough anyway).

JQuery is a device that is used for two purposes:

1. The intention is that maybe sometime in the future Joomla will be
able to support other DB engines, and this could perform necessary
transformations on the SQL (similar to what ADODB does).

2. It greatly assists the preparation of SQL statements in
non-sequential ways. If you take a look at say the backend
com_content articles model, there are optional filters and the query
class allows you to collect the extra selected, joins and wheres
within a logical grouping. 1.5 does the same thing only with arrays
of $wheres, $joins and so on. It's simply a cleaner way to approach
the problem of building complex queries and especially neat when used
in conjunction with PHP 5's __toString magic function. I've had the
same comment "why bother" come up time and again until the person
actually starts using it for anything but the most simple of queries,
then they "get it" :) (generally).

While it can be overkill to use JQuery for the most simple jobs, the
consensus was that if we are going to use it in some places, it
should be used everywhere. As of today, that is not the case but
should be the goal. Obvious we need to add support for operations
other than just SELECT.

On reflection, I think JDatabase and JTable have been probably some of
the most successful implementations for making Joomla development easy
(not perfect by any means, but easy). Their predecessors served Mambo
and dotProject well. Hopefully JQuery (of the SQL persuasion <cough>)
will prove equally useful.

Anyway, that's the history lesson :)

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/11/22 Paladin <arlen....@gmail.com>:

[Mitch Pirtle]

On Mon, Nov 23, 2009 at 10:06 PM, Andrew Eddie <mamb...@gmail.com> wrote:
>
> Hi Arlen.
>
> JDatabase is just an abstraction layer for providing database engine
> connectivity.  It was originally done at the behest of "why can't we
> run on Postgres" and once completed, those people failed to deliver.
> Maybe one day we will get to cross-platform nirvana, but for now
> JDatabase is useful for creating secondary connectors to other
> business systems.  I've certainly used MSSQL (painful as it is) and
> Omar has done one for Oracle.

I'd debate that with you Andrew - without addressing all that
MySQL-specific SQL (at the time JDatabase was implemented) scattered
throughout the entire code base, there was absolutely no way anyone
could work with anything other than MySQL.

This is a really good example of why JQuery is on the critical path
for database independence. JQuery is a must if you want to have Joomla
functional across MySQL, PostgreSQL, Oracle and DB2. With engines that
don't execute SQL at all (such as my beloved MongoDB) JQuery is the
only way to get the core of Joomla functioning without SQL.

-- Mitch