Long term improvements tasks

1 2 next

Piotr Pokora

Long term improvements tasks
Tue November 24 2009 13:05:09 UTC
Hi!

I have few proposals and would like everybody to think about them.
We could start discussion in a week or two.

# MgdSchema

With every major relase we add more and more attributes to properties or
classes. This makes (and will make) MgdSchemas a bit unreadable.
This is ad-hoc idea, but what about layout like this:

<property name="foo">
<descriptio>Blah</description>
<user_fields>
<a>Bar</a>
<b>true</b>
<user_fields>
<unique>true</unique>
<private>false</private>
<required>true</required>
</property>

Now, when we do not have multilang and do not have to worry about
backward/legacy features, we can redesign it (with mRFC first obviously).

# Query Builder

Everybody expects many features from QB. The more we add them the more
problems we are going to have in a future.
It's been discussed already, but we must change QB class API, add
abstract class, interfaces, etc.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] Long term improvements tasks
Mon November 30 2009 17:55:06 UTC
Hi!

> # Query Builder

First proposal. Not perfect, but I think good enough to start
discussion. All examples in pseudo language.

# MidgardQueryConstraint class

## Methods

* constructor (property, operator, constraint)
* set_property (property)
* set_operator (operator)
* set_constraint (constraint value)
* set_constraint_with_property (property constraint value)
* get_property ()
* get_operator ()
* get_constraint ()
* get_constraint_with_property ()

### Example

constraint = qb.add_constraint ("name", "=", "Foo")
if (something)
constraint.set_constraint ("Bar")

# MidgardQueryProfiler

## Methods

* get_sql
* get_execution_time

### Example

qb.execute()
profiler = qb.get_profiler()
print Query profiler.get_sql() took profiler.get_execution_time()

# Abstract class MidgardQuery (also might be an interface)

## Methods

* add_constraint (property, operator, constraint value)
* add_constraint_with_property (property, operator, property constraint
value)

Both would return MidgardQueryConstraint object

* can be reused
* all constraint data can be changed during runtime
* compatible with current implementation

* add_order
* set_limit
* set_offset
* get_query_profiler ()
* list_constraints ()
* add_join (MidgardQueryJoin, on property)

# MidgardQueryJoin extends MidgardQuery

* constructor (join type, target class, target property)

### Example

qj = new midgard.query.join (LEFT_JOIN_TYPE, "my_blog", "creator")
qb = new midgard.query.builder ("person")
qb.add_join (qj, "guid")

# MidgardQueryGroup extends MidgardQuery

* constructor (group type)

### Example

qb = new midgard.query.builder ("person")

group = new midgard.query.group ("OR")
group.add_constraint ("name", "=", "Foo")
group.add_constraint ("name", "=", "Bar")

qb.add_constraint ("phone", "=", "+123456789")
qb.add_group (group)
qb.execute()

# MidgardQueryBuilder extends MidgardQuery

* constructor (class)
* add_group (MidgardQueryGroup)
* include_deleted()
* execute () Returns array of objects.

No examples, keep current API.

# MidgardQueryCursor extends MidgardQuery

* constructor (class)
* add_group (MidgardQueryGroup)
* include_deleted()
* execute () Returns void.
* get_elements()
* get_object_at_position

### Example

qc = new midgard.query.cursor ("person")
qc.add_constraint ("name", "=", "Alice")
qc.execute()

elements = qc.get_elements()

for (i = 0; i < elements; i++)
{
person = qc.get_object_at_position (i)
if (person.lastname == "in wonderland")
{
print "Alice from person.city is in wonderland"
break;
}
}

It could be resolved different way, but might make sense if you have
1.000.000 persons, and
expect only 100 of them with name "Alice". Anyway, it's just an example.

# MidgardCollector extends MidgardQueryBuilder

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] Long term improvements tasks
Tue December 01 2009 20:55:09 UTC
Hi!

>> # Query Builder
>
> # MidgardQueryBuilder extends MidgardQuery

I wonder. What about keeping MidgardQueryBuilder as it is and provide
new MidgardQueryObject class? This way, we do not have to worry much
about backward compatibility and new class name explains more what it is
designed for.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Henri Bergius

Re: [midgard-dev] Long term improvements tasks
Wed December 02 2009 08:28:19 UTC
On Tue, Dec 1, 2009 at 10:48 PM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
> I wonder. What about keeping MidgardQueryBuilder as it is and provide
> new MidgardQueryObject class? This way, we do not have to worry much
> about backward compatibility and new class name explains more what it is
> designed for.

Makes sense. We anyway need to have the replacement available for a
release or two before deprecating the old query API.

> Piotras

/Bergie

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/

My Royal Enfield Bullet 500 is for sale, see http://www.nettimoto.com/844397
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Alexey Zakhlestine

Re: [midgard-dev] Long term improvements tasks
Wed December 02 2009 10:55:06 UTC
On 30.11.2009, at 20:46, Piotr Pokora wrote:

>
> Hi!
>
>> # Query Builder
>
> First proposal. Not perfect, but I think good enough to start
> discussion. All examples in pseudo language.

1) I think we discussed this before, and you liked my proposal to use OOP-style for properties/constraints. should we try those, instead?
2) If we do, then there's no need to introduce separate concepts of properties and constraints. There's just "left part" and "right part" and anything can be on each of the sides.

I can elaborate to remind details of what I am talking about

_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] Long term improvements tasks
Wed December 02 2009 13:55:10 UTC
Alexey Zakhlestin pisze:

Hi!

>>> # Query Builder
>> First proposal. Not perfect, but I think good enough to start
>> discussion. All examples in pseudo language.
>
> 1) I think we discussed this before, and you liked my proposal to use OOP-style for properties/constraints. should we try those, instead?
> 2) If we do, then there's no need to introduce separate concepts of properties and constraints. There's just "left part" and "right part" and anything can be on each of the sides.
>
> I can elaborate to remind details of what I am talking about

Please do.
I am not very happy with two different ways, but all in all it's clear
and doesn't do any voodoo. Which might happen IMO.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Alexey Zakhlestine

Re: [midgard-dev] Long term improvements tasks
Mon December 07 2009 12:25:06 UTC
On 02.12.2009, at 16:49, Piotr Pokora wrote:

> Alexey Zakhlestin pisze:
>
> Hi!
>
>>>> # Query Builder
>>> First proposal. Not perfect, but I think good enough to start
>>> discussion. All examples in pseudo language.
>>
>> 1) I think we discussed this before, and you liked my proposal to use OOP-style for properties/constraints. should we try those, instead?
>> 2) If we do, then there's no need to introduce separate concepts of properties and constraints. There's just "left part" and "right part" and anything can be on each of the sides.
>>
>> I can elaborate to remind details of what I am talking about
>
> Please do.
> I am not very happy with two different ways, but all in all it's clear
> and doesn't do any voodoo. Which might happen IMO.

Ok.

So, I propose API similar to the one I use in http://github.com/indeyets/mysql-query-builder

// example with OR
$q = new SelectQuery(new Table('person'));
$q->setCondition(new OrOp(
new Condition('=', new Field('name'), new Parameter('Foo')),
new Condition('=', new Field('name'), new Parameter('Bar')),
));
$q->setLimit(100);
$q->execute();

// example with join
$tbl1 = new Table('person');
$tbl2 = new Table('my_blog');

$q = new SelectQuery($tbl1);
$q->addLeftJoin($tbl2, new Field('creator', $tbl2));
$q->setCondition(new Condition('<>', new Field('name', $tbl1), new Parameter('root')));

That's the general idea. Anything is an object.
Of course, in the obvious cases we can add simple-paths. If query involves only one table, there's no need to specify table as a second parameter to Field().
If we don't have other use for the Table object we can just specify it as string.:

$q = new SelectQuery('person');

Similar with Parameter. Conditions should treat literals as Parameters:

new Condition('=', new Field('name'), 'Foo'); // <-- this is ok

It is possible to specify 2 fields or even 2 parameters in Condition:

new Condition('=', new Field('name', $tbl1), new Field('name', $tbl2);
new Condition('!=', 'Foo', 'Bar'); // equivalent of new Condition('!=', new Parameter('Foo'), new Parameter('Bar'));

This approach will end as a very clean and easily testable and extendable API.
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] Long term improvements tasks
Mon December 07 2009 12:45:06 UTC
Alexey Zakhlestin pisze:

Hi!

> So, I propose API similar to the one I use in http://github.com/indeyets/mysql-query-builder
>
> // example with OR
> $q = new SelectQuery(new Table('person'));

What is Table object and why do we need this?

> $q->setCondition(new OrOp(
> new Condition('=', new Field('name'), new Parameter('Foo')),
> new Condition('=', new Field('name'), new Parameter('Bar')),
> ));

Why should we change constraint to condition?

> // example with join
> $tbl1 = new Table('person');
> $tbl2 = new Table('my_blog');
>
> $q = new SelectQuery($tbl1);
> $q->addLeftJoin($tbl2, new Field('creator', $tbl2));
> $q->setCondition(new Condition('<>', new Field('name', $tbl1), new Parameter('root')));

How can we set additional condition for joined table?

>
> That's the general idea. Anything is an object.
> Of course, in the obvious cases we can add simple-paths. If query involves only one table, there's no need to specify table as a second parameter to Field().
> If we don't have other use for the Table object we can just specify it as string.:
>
> $q = new SelectQuery('person');
>
> Similar with Parameter. Conditions should treat literals as Parameters:
>
> new Condition('=', new Field('name'), 'Foo'); // <-- this is ok
>
> It is possible to specify 2 fields or even 2 parameters in Condition:
>
> new Condition('=', new Field('name', $tbl1), new Field('name', $tbl2);
> new Condition('!=', 'Foo', 'Bar'); // equivalent of new Condition('!=', new Parameter('Foo'), new Parameter('Bar'));

Foo is property name and Bar is a constraint value?

> This approach will end as a very clean and easily testable and extendable API.

It looks low level a bit. I think we need something simpler and more
"midgardized". If we would like to go with such low level API we could
use GDA routines directly.

Besides (pure theory right now), we need something which doesn't look
like SQL. Class storage could be xml file, custom filesystem or some non
SQL database.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Alexey Zakhlestine

Re: [midgard-dev] Long term improvements tasks
Mon December 07 2009 12:55:06 UTC
On 07.12.2009, at 15:36, Piotr Pokora wrote:

> Alexey Zakhlestin pisze:
>
> Hi!
>
>> So, I propose API similar to the one I use in http://github.com/indeyets/mysql-query-builder
>>
>> // example with OR
>> $q = new SelectQuery(new Table('person'));
>
> What is Table object and why do we need this?

Let's call it ObjectClass ;)
We're not talking about terminology right now. Let's get to agreement on approach :)

>
>> $q->setCondition(new OrOp(
>> new Condition('=', new Field('name'), new Parameter('Foo')),
>> new Condition('=', new Field('name'), new Parameter('Bar')),
>> ));
>
> Why should we change constraint to condition?

Same as above.
I just copypasted it from my project. "Constraint" is fine

>
>> // example with join
>> $tbl1 = new Table('person');
>> $tbl2 = new Table('my_blog');
>>
>> $q = new SelectQuery($tbl1);
>> $q->addLeftJoin($tbl2, new Field('creator', $tbl2));
>> $q->setCondition(new Condition('<>', new Field('name', $tbl1), new Parameter('root')));
>
> How can we set additional condition for joined table?

We just use new Field('name', $tbl2) in Constraing.
($tbl2 is a joined table here)

>> That's the general idea. Anything is an object.
>> Of course, in the obvious cases we can add simple-paths. If query involves only one table, there's no need to specify table as a second parameter to Field().
>> If we don't have other use for the Table object we can just specify it as string.:
>>
>> $q = new SelectQuery('person');
>>
>> Similar with Parameter. Conditions should treat literals as Parameters:
>>
>> new Condition('=', new Field('name'), 'Foo'); // <-- this is ok
>>
>> It is possible to specify 2 fields or even 2 parameters in Condition:
>>
>> new Condition('=', new Field('name', $tbl1), new Field('name', $tbl2);
>> new Condition('!=', 'Foo', 'Bar'); // equivalent of new Condition('!=', new Parameter('Foo'), new Parameter('Bar'));
>
> Foo is property name and Bar is a constraint value?

No. Both are values. That doesn't make much sense, but is perfectly ok from query-valididy point of view.

>> This approach will end as a very clean and easily testable and extendable API.
>
> It looks low level a bit. I think we need something simpler and more
> "midgardized". If we would like to go with such low level API we could
> use GDA routines directly.
>
> Besides (pure theory right now), we need something which doesn't look
> like SQL. Class storage could be xml file, custom filesystem or some non
> SQL database.

It is not really lower than what you proposed. Syntax is a bit more detailed, but that gives us flexibility and "shortcuts" remove complexity when it is not needed.
We can do some side-by-side comparisons :)

_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] Long term improvements tasks
Mon December 07 2009 13:35:08 UTC
Alexey Zakhlestin pisze:

Hi!

>>> // example with OR
>>> $q = new SelectQuery(new Table('person'));
>> What is Table object and why do we need this?
>
> Let's call it ObjectClass ;)
> We're not talking about terminology right now. Let's get to agreement on approach :)

I think we must focus on API strictly.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply

1 2 next