12 |
developing and looking into code usage (if it's not documented and tested, |
developing and looking into code usage (if it's not documented and tested, |
13 |
it doesn't exist) but this part is delivered as pure POD for reading pleasure. |
it doesn't exist) but this part is delivered as pure POD for reading pleasure. |
14 |
|
|
15 |
|
=head1 Models |
16 |
|
|
17 |
|
Models in Jifty are at perl level objects (with validation and |
18 |
|
canonicalization) and tables in database. |
19 |
|
|
20 |
|
For a start, we implement some magic documented in L<A3C::Record> on records |
21 |
|
(rows in database). |
22 |
|
|
23 |
|
Then, we need to mungle data without re-thinking SQL queries which would |
24 |
|
produce same results, so there is L<A3C::SQL> which produce objects that |
25 |
|
look like L<Jifty::Collection>s, but aren't. This allows us to switch into |
26 |
|
SQL in views if needed. |
27 |
|
|
28 |
|
This method is not perfect, and shouldn't be used instead of Jifty models |
29 |
|
just to write SQL because it doesn't do any permission checking. However, |
30 |
|
it's a huge help for compex C<GROUP BY> and C<JOIN> queries which are hard |
31 |
|
to express using L<Jifty::DBI>. |
32 |
|
|
33 |
|
If we needed to generate those queries from within program (from user data, |
34 |
|
for example) something like L<Fey::SQL> would be much better tool. |
35 |
|
|
36 |
=head1 LDAP |
=head1 LDAP |
37 |
|
|
38 |
Implement LDAP entry and edit interface (insteresting problem since most |
Implement LDAP entry and edit interface (insteresting problem since most |
39 |
values can have multiple entries which doesn't map nicely to relational |
entries can have multiple values which doesn't map nicely to relational |
40 |
schema) |
schema). |
41 |
|
|
42 |
|
=head2 Multiple values |
43 |
|
|
44 |
|
When creating records with ARRAY values C<A3C::Record/create> |
45 |
|
joins values with magic marker between them to make rest of Jifty happy. |
46 |
|
|
47 |
|
Plan is to use full-text search engine to search over data anyway, so this |
48 |
|
is not serious limitation. If needed, something like bitmap indexes could be |
49 |
|
used at database level to expose thouse values for filtering. For joins we |
50 |
|
would probably need separate materialized many-many tables which could be |
51 |
|
created more-or-less automatically in L<A3C::Record>. |
52 |
|
|
53 |
This can in turn be broken down into following tasks: |
This can in turn be broken down into following tasks: |
54 |
|
|
55 |
=head2 Import data from existing LDAP server |
=head2 Import data from existing LDAP server |
56 |
|
|
57 |
C<bin/import-ldap.pl> has embedded documentation |
C<bin/import-ldap.pl> has embedded documentation and uses <A3C::LDAP> |
58 |
|
|
59 |
|
L<http://a3c.skole.hr/ldap/> is user interface to L<A3C::View::LDAP> and |
60 |
|
L<A3C::Action::SyncOrganization> |
61 |
|
|
62 |
=head2 Query existing LDAP server |
=head2 Query existing LDAP server |
63 |
|
|