Java+entity beans

[anon]

Εχω κολλήσει σε ένα σημείο και η όποια βοήθεια ευπρόσδεκτη. Οχι ότι δεν έψαξα, δυο μέρες παιδεύομαι.

Είμαι σε φάση εκπαίδευσης Java με entity beans και χρήση κάποιου persistance layer. Ως IDE χρησιμοποιώ το Netbeans, και σαν persistance layer το toplink, βάση MySQL. Ολα oracle δηλαδή, java, netbeans ide, toplink persistence layer, mysql database (τουλάχιστον δεν μπορεί να πεί κανείς ότι φταίει η άλλη εταιρία )

Kάνοντας ένα application μέσω του έτοιμου framework, όλα καλά, με ένα table ή και με δυο (master / detail). To πρόβλημά μου όμως είναι όταν έχω δυο πίνακες που δεν θέλω να χρησιμοποιήσω σαν σχέση master/detail αλλά ως αναφορά δεδομένων αλλού (πχ σε πίνακα πελατών, κωδικός πωλητή) και να συνδιάσω τα δυο entity beans που βλέπουν τα αντίστοιχα tables, επιτρέποντάς μου όμως την αλλαγή του πεδίου που είναι foreign key απο το customer στον πωλητή. Μήπως παίζει ρόλο που στον χαρακτηρισμό του entity bean δίνω @ΜanyToOne; Μήπως πρέπει να το δηλώσω @OneToOne; Θέλω να μπορώ να αλλάζω τον κωδικό του πωλητή στον πελάτη, να μην πάει και το αλλάζει στον πωλητή (αυτό μου κάνει τώρα) και να έχω τo entity bean του πωλητή "δεμένο" απλώς για να μου φέρνει το όνομα του πωλητή που το κάνω bind σε κάποιο πεδίο στην φόρμα.

ΥΓ. Παράδειγμα που διάβαζα
http://netbeans.org/kb/67/java/gui-db-custom.html

[moshstef]

ManyToOne είναι το σωστό relationship. (Πολλοί πελάτες έχουν τον ίδιο πωλητή, σωστά ; )

Ερώτηση:

Μήπως κάνεις κάτι του στυλ:

customer.getSeller().setId(123);

Οπότε αλλάζεις τον κωδικό του seller που κάνει reference o customer.

Ενώ θα έπρεπε να κάνεις κάτι σαν:

customer.setSeller(otherSeller);

που αλλάζει τον seller του customer με άλλο seller;

Από toplink δεν ξέρω αλλά σε JPA ή Hibernate κάπως έτσι είναι.

[anon]

To @ManyToOne τελικά δεν πρέπει ναναι το σωστό υπο την παρούσα συνθήκη. Αυτό απο ότι είδα ισχύει για σχέσεις master/detail, όπως πχ παραγγελία και οι γραμμές της παραγγελίας που δένουν πχ με τον κωδικό της παραγγελίας. Τελικά με το @OneToOne δούλεψε. Περίπου.
Δηλαδή συμπεριφέρεται σχεδόν σωστά, και λέω σχεδόν, γιατι όταν αλλάζει το πεδίο του κωδικού πωλητή, δεν αλλάζει το όνομα. Προφανώς το entity bean δεν παίρνει χαμπάρι την αλλαγή (παρα μόνο όταν του δώσεις το event για σώσιμο), οπότε και το referenced πεδίο (ονομα πωλητή) δεν αλλάζει. Μήπως γνωρίζετε πως μπορώ να το κάνω αυτό; ΟΚ, παίρνω το event απο το textfield πεδίο, τι πρέπει να κάνω για να πάρει χαμπάρι το entity bean ότι άλλαξε και να μου φέρει το σωστό όνομα; με το set method; (όλα αυτά τα persistance λίγο πολύ ίδια πρεπει ναναι).

υποτίθεται ότι αυτά είναι trivial και βλέπω ότι έχει τέτοιο μπλέξιμο, που με κάνει να απορώ πως και γιατί χρησιμοποιούν Java τελικά.... Ακόμα και σε Cobol πιο εύκολα είναι...

[PGouv]

Cobol φιλε μου ειναι μια χαρά απλά και δουλευουν εως σημερα , υπάρχει ακομα και με .NET. Ειναι και επεκτασιμη με δικες σου βιβλιοθηκες. .

Ειχα υλοποιησει δυο Project με ΤopLink και μου πηρε παρα πολυ καιρό να τελειώσω..
Πιστευω πως στη Java παρα ειναι πολυπλοκα πολλα πραγματα.Για να οφεληθεις απο κατι τετοιο πιστευω μονο αν δουλευεις σε ομαδα και καθημερινά μεχρι να το μαθεις καλά.

Με το toplink ειχα βρει 4 bugs που επρεπε να περιμενω την νεα εκδοση να διορθωθουν! Τα 3 τα ειχαν βρει και αλλοι το ενα εγώ... Απειρα *σταυριδια και χαμενες ωρες πολυτιμες...
Το καλο ειναι πως μπορουσες να τρεξεις δικα σου query και να τα αντιστοιχίσει σε Entity beans..

Τελικά πιστευω πως δεν μου χρειάζεται και απλες εντολες sql ειναι καλυτερη λύση για μενα τουλαχιστον.

Για αυτο σκεψου να το παρατησεις και να βρεις την υγεια σου.... αλλιως θελει πολυ ψαξιμο και περα απο documentation για να καταλαβεις τι γινεται και πως...

Οσο για το προβλημα σου καμια φορα τα κρατάει στην cache ,μηπως εκει ειναι το προβλημα σου;

[anon]

Tελικα όλα αυτά τα layers δίδουν φοβερή ευκολία όταν κάνεις συνέχεια τα ίδια πράγματα, για τα οποία έχουν φτιαχτούν, αλλά και σου προσθέτουν απίστευτη δυσκολία (απο την μέχρι στιγμης εμπειρία μου) εαν ξεφεύγεις έστω και λίγο απο την πεπατημένη τους, χώρια ένα κάρο προβλήματα ασυμβατοτήτων. Αλλα δουλεύουν με άλλη έκδοση άλλα με άλλη, ένας χαμός. Σαν να χτιζεις jenga.

[mpetou]

πριν πας με σχεσιακη βαση δες αυτο
http://neo4j.org
τετοιες λυσεις ειναι το μελλον..

για το παρον δες αυτο
http://www.mybatis.org
και ενα συντομο tutorial
http://www.tutorialspoint.com/ibatis/index.htm

[nikospara]

Καλησπέρα,

To @ManyToOne τελικά δεν πρέπει ναναι το σωστό [...] με το @OneToOne δούλεψε.

Θα συμφωνούσα με τον moshstef. Σε τελική ανάλυση εσύ ξέρεις πώς πρέπει να είναι η σχέση, αλλά το λογικό μου φαίνεται "Πολλοί πελάτες έχουν τον ίδιο πωλητή" => @ManyToOne από τον πελάτη στον πωλητή.

Δηλαδή συμπεριφέρεται σχεδόν σωστά, και λέω σχεδόν, γιατι όταν αλλάζει το πεδίο του κωδικού πωλητή, δεν αλλάζει το όνομα. Προφανώς το entity bean δεν παίρνει χαμπάρι την αλλαγή (παρα μόνο όταν του δώσεις το event για σώσιμο), οπότε και το referenced πεδίο (ονομα πωλητή) δεν αλλάζει. Μήπως γνωρίζετε πως μπορώ να το κάνω αυτό; ΟΚ, παίρνω το event απο το textfield πεδίο, τι πρέπει να κάνω για να πάρει χαμπάρι το entity bean ότι άλλαξε και να μου φέρει το σωστό όνομα; με το set method; (όλα αυτά τα persistance λίγο πολύ ίδια πρεπει ναναι).

Τι application framework χρησιμοποιείς; Γιατι μάλλον με αυτό έχει να κάνει το συγκεκριμένο πρόβλημα, όχι με το persistence layer. Κώδικας;

υποτίθεται ότι αυτά είναι trivial και βλέπω ότι έχει τέτοιο μπλέξιμο, που με κάνει να απορώ πως και γιατί χρησιμοποιούν Java τελικά.... Ακόμα και σε Cobol πιο εύκολα είναι...

Υπομονή, θα σε ανταμείψει...

[mpetou]

το relational οτι περιτύλιγμα και να του βαλεις OO δεν γινεται
το graph ομως γινετε ΟΟ

χωρις layers κτλπ κτλπ
το κανεις οπως ειναι στην πραξη το μοντελο..

[moshstef]

Anon αν είναι ακόμα υπό συζήτηση η χρήση του Toplink και των EJB θα σου πρότεινα να δοκιμάσεις με Spring για service layer και, αν γνωρίζεις SQL, το MyBatis για data access όπως προτείνει και ο χρήστης mpetou. Μιλάμε για μέρα με την νύχτα.

[anon]

Προς το παρόν δεν προλαβαίνω να ασχοληθώ με τα διάφορα frameworks. Χρησιμοποιώ Netbeans, όχι γιατί το Eclipse δεν είναι καλό (το έχω χρησιμοποιήσει για C και λίγο για Java) αλλα επειδή το Netbeans έχει καλό GUI designer.

Στην τελική, σίγουρα η χρήση κάποιου persistence layer μαζί με κάποιο άλλο framework μπορεί να σου πολλαπλασιάσει την παραγωγικότητα εξαιρετικά, το θέμα είναι ότι πρέπει να μάθεις όχι απλά μια γλώσσα, αλλά όλες τις βιβλιοθήκες / frameworks και πως παίζουν μεταξύ τους. Αυτό απαιτεί είτε να έχεις κάποιον μέντορα που τα ξέρει να σε καθοδηγήσει στα πρώτα μονοπάτια, τουλάχιστον να ξεμπερδεύεις με τις "λάσπες", διαφορετικα πρέπει να σπαταλήσεις πολύ χρόνο με προσπάθεια, δοκιμές και εμπειρία για να χτίσεις την απαραίτητη τεχνογνωσία.

Πχ η χρήση @ManyToOne ή @OneToOne. Το λογικό ειναι many to one. Δεν παίζει σωστά. Γιατί ο πελάτης έχει έναν πωλητή, πολλοί πελάτες ανήκουν σε έναν πωλητή, αλλά είναι τελείως διαφορετική σχέση απο το μια παραγγελία στην οποία ανήκουν πολλές γραμμές. Στον πελάτη μπορείς να αλλάξεις τον πωλητή, κάτι που δεν μπορείς, δεν στέκει λογικά, σε μια γραμμή παραγγελίας, και μόνον σε αυτή, να αλλάξεις τον κωδικό παραγγελίας (header/master) στο οποίο αναφέρεται. Αλλης μορφής είναι η μια σχέση, άλλη η άλλη, απο το γεγονός ότι στο "detail" εαν μπορεις ή όχι να αλλάξεις την αναφορά του μαστερ και μόνο σε μια γραμμή του detail. Ετσι, τελικά απο δοκιμές, βρήκα ότι το ManyToOne δεν συμπεριφέρεται όπως θέλω, αλλά το OneToOne.

Επίσης το persistence layer κάνει caching, που ναι μεν είναι καλό, αλλά σε συγκεκριμένη περίπτωση δεν παίζει καλά (*). Εχω τον πελάτη, και μπορώ να μεταβάλω τα στοιχεία του. Εχω κωδικό πωλητή και δίπλα το όνομα του (αυτό πλέον δουλεύει). Αλλάζω (ή νέα καταχώρηση) κωδικό πωλητή. Δεν εμφανίζει τίποτα στο πεδίο όνομα πωλητή, γιατί δεν έχουν πάει οι αλλαγές στην βάση, δεν μπορώ να ζητήσω refresh γιατί κάνει query στην βάση (και θα μου χαλάσει ότι αλλαγές έχω κάνει επάνω στην φόρμα χώρια που δεν θα μου φέρει το σωστό). Σίγουρα πρέπει να υπάρχει τρόπος, δεν μπορώ να φανταστώ εμπορικές εφαρμογές, που αυτά είναι εξαιρετικά trivial, να μην παίζουν, αυτό που με σκάει είναι ότι ούτε tutorials ούτε οτιδήποτε το έχουν αυτό, που είναι το Α και το Ω τυπικών εφαρμογών που έχουν δεδομένα που εμφανίζονται σε μια φόρμα απο περισσότερους απο έναν πίνακες. Με έναν πίνακα; Ευχαριστώ πολύ, δεν θα πάρω.

Αναγκάστηκα και έκανα πρόγραμμα χωρις persistence layer, entity beans και όλα τα σχετικά, πλήρως manually. Εβαλα listener (άλλο πονεμένο σημείο, να μην έχει ένα event της μορφής on changed text στο jtextfield, κυριολεκτικά έλεος, πρέπει να τα πιάνω πλήκτρο - πληκτρο; σε ποιό αιώνα ζούμε; και τόψαξα και πολύς κόσμος το ίδιο παράπονο / γκρίνια έχει, ένα μαμημένο event ότι μόλις γίνει accepted το textfield, δηλαδή εαν πατήσει enter/tab ή κάνει focus αλλου, να μου πετάξει ένα event, εφόσον έχει αλλάξει και μόνο τότε, το περιεχόμενο του!, ζητάω πολλά;;;;;; ) και το έκανα χεράτα, με jdbc driver επικοινωνία με την βάση κλπ κλπ κλπ...

Αλλο σημείο εδώ... Σκέφτηκα, απο όσο ξέρω δηλαδή, επειδή "κοστίζει" πολύ το άνοιγμα της σύνδεσης, να το ανοίξω μια φορά, και να χρησιμοποιώ σε διάφορα σημεία (packages) το connection. Αμ δε. Ψάχνοντας αρκετά, διάβασα ότι δεν προτείνετε, δεν παίζει, εαν θέλεις κάτι τέτοιο, θα πρέπει να βάλεις ένα connection pool manager, και επειδή υποτίθεται ότι δεν κοστίζει και πολύ το ανοιγμα της σύνδεσης με βάση, να το κάνεις κάθε φορά που χρειάζεσαι... Μπορεί και να έχουν δίκιο... Εαν ποτέ έχω χρόνο, ίσως το μετρήσω, για να το έχω και με νούμερα, εαν "κοστίζει" και πόσο.

Ενδιαφέρον αυτό που λέτε για το MyBatis, θα το κοιτάξω. απλά θέλω να τελειώσω κάτι, και τελικά ο χρόνος που απαιτείται για να κάνεις μόνο να δουλέψουν τα διάφορα layers και frameworks είναι τελικά πολύς, και αξίζει εαν κάνεις αυτό το πράγμα συνέχεια, ώστε να κερδίσεις μετά στην πορεία.

(*) Για να είμαι σωστός, δεν τα ξέρω καλά, ώστε να τα δουλεύω καλά.

ΥΓ. Xρησιμοποιώ Netbeans 7 ( kai 6.9.1), Swing Application Framework (JSR-296), Toplink (toplink essentials), mysql-connector-java-5.1.13 & Java 1.6 (update23).

[moshstef]

Anon, δικό σου είναι το project, και εσύ αποφασίζεις για τις τεχνολογίες που θα χρησιμοποιήσεις. Όμως θα σου πω μερικά πράγματα από την εμπειρία μου που θεωρώ σημαντικά και ίσως σε γλιτώσουν από άσκοπη ταλαιπωρία, γιατί υπάρχουν πολύ πιο απλοί τρόποι να γίνουν κάποια πράγματα απ΄ότι χρησιμοποιώντας τις τεχνολογίες που έχεις επιλέξει.

Είναι γνωστό ότι το toplink είναι πανάθλιο από άποψη δυσκολίας στον κώδικα. Είδα λίγο το παράδειγμα και ζαλίστηκα. Προσωπικά αφόυ ταλαιπωρήθηκα με Hibernate και JPA πλεον αποφεύγω οποιοδήποτε ORM και προτιμώ να χρησιμοποιήσω MyBatis ή ακόμα και JDBC στην τελική.

Επίσης πλεον ο περισσότερος κόσμος χρησιμοποιεί spring και δεν ασχολείται με τα connection pools σε τέτοιο επίπεδο. Στο spring απλά δηλώνεις ένα datasource (το οποίο χρησιμοποιεί connection pool) στο configuration και το περνάς σε ένα JdbcTemplate που χρησιμοποιείς για να εκτελέσεις τα queries σoυ. Ξεχνάς δηλαδή το δώσε connection, κλείσε connection. Επίσης τα transactions μπορούν να γίνουν πολύ απλά με annotations.

[anon]

Είναι γνωστό ότι το toplink είναι πανάθλιο από άποψη δυσκολίας στον κώδικα. Είδα λίγο το παράδειγμα και ζαλίστηκα. Προσωπικά αφόυ ταλαιπωρήθηκα με Hibernate και JPA πλεον αποφεύγω οποιοδήποτε ORM και προτιμώ να χρησιμοποιήσω MyBatis ή ακόμα και JDBC στην τελική.

Το κατάλαβα και εγώ, the hard way. Αφού σπατάλησα, "άπειρες" ώρες... Παίζω τώρα με JDBC, τουλάχιστον αυτό δουλεύει, και θα δώ όταν έχω ευκαιρία και το mybatis.

Επίσης πλεον ο περισσότερος κόσμος χρησιμοποιεί spring και δεν ασχολείται με τα connection pools σε τέτοιο επίπεδο. Στο spring απλά δηλώνεις ένα datasource (το οποίο χρησιμοποιεί connection pool) στο configuration και το περνάς σε ένα JdbcTemplate που χρησιμοποιείς για να εκτελέσεις τα queries σoυ. Ξεχνάς δηλαδή το δώσε connection, κλείσε connection. Επίσης τα transactions μπορούν να γίνουν πολύ απλά με annotations.

Δεν έχω αρκετό χρόνο να το κοιτάξω τώρα, αλλά θα το έχω υπόψιν. Τα connections είναι copy/paste ο ίδιος κώδικας, όχι ότι καλύτερο βέβαια να επαναλαμβάνεις τις ίδιες γραμμές εδώ και εκεί, αλλά θα δω τι μπορεί να γίνει σε αυτόν τον τομέα μετά.

[PGouv]

Αν κανεις desktop εφαρμογή δε χρειάζονται πολλές συνδέσεις στη βάση.. Να ανοιγεις συνδεση καθε φορα ναι μεν κοστίζει αλλα τεραστια site οπως το wordpress στην αρχη ετσι δουλευε, δλδ και τοσο υψηλο επιπεδο δεν ασχοληθηκαν με αυτο το θεμα... απλα ανοιγαν μια νεα συνδεση....

Στο connection pooling επειδη το ειχα ψαξει λίγο το .close() ειναι απαραίτητο αλλα στην ουσια δεν κανει close απλα επιστρεφει τη συνδεση στη πισινα για να μπορει να το παρει αλλος... Δλδ αν τρεχουν 500 πελατες ταυτοχρονα θα εχεις 500 συνδεσεις ταυτόχρονα και παλι.. δε μοιραζεται η ιδια συνδεση ποτε!

Με το JDBC αν τα οργανώσεις σωστα θα εισαι εντάξει.. Καποιο pattern πχ

[Mimisss]

Εχω κολλήσει σε ένα σημείο και η όποια βοήθεια ευπρόσδεκτη. Οχι ότι δεν έψαξα, δυο μέρες παιδεύομαι.

Είμαι σε φάση εκπαίδευσης Java με entity beans και χρήση κάποιου persistance layer. Ως IDE χρησιμοποιώ το Netbeans, και σαν persistance layer το toplink, βάση MySQL. Ολα oracle δηλαδή, java, netbeans ide, toplink persistence layer, mysql database (τουλάχιστον δεν μπορεί να πεί κανείς ότι φταίει η άλλη εταιρία )

Kάνοντας ένα application μέσω του έτοιμου framework, όλα καλά, με ένα table ή και με δυο (master / detail). To πρόβλημά μου όμως είναι όταν έχω δυο πίνακες που δεν θέλω να χρησιμοποιήσω σαν σχέση master/detail αλλά ως αναφορά δεδομένων αλλού (πχ σε πίνακα πελατών, κωδικός πωλητή) και να συνδιάσω τα δυο entity beans που βλέπουν τα αντίστοιχα tables, επιτρέποντάς μου όμως την αλλαγή του πεδίου που είναι foreign key απο το customer στον πωλητή. Μήπως παίζει ρόλο που στον χαρακτηρισμό του entity bean δίνω @ΜanyToOne; Μήπως πρέπει να το δηλώσω @OneToOne; Θέλω να μπορώ να αλλάζω τον κωδικό του πωλητή στον πελάτη, να μην πάει και το αλλάζει στον πωλητή (αυτό μου κάνει τώρα) και να έχω τo entity bean του πωλητή "δεμένο" απλώς για να μου φέρνει το όνομα του πωλητή που το κάνω bind σε κάποιο πεδίο στην φόρμα.

ΥΓ. Παράδειγμα που διάβαζα
http://netbeans.org/kb/67/java/gui-db-custom.html

Δεν έχω ιδέα από το framework που χρησιμοποιείς και συγγνώμη εκ των προτέρων αν σε μπερδέψω. Εξαιρουμένου του framework λοιπόν, εχω την εντύπωση οτι έχεις μπερδέψει 2 πράγματα: την σχεδίαση του μοντέλου της βάσης με την λειτουργία του UI.
Ένα είναι σίγουρο 100%: η σχέση των πινάκων Πωλητές - Πελάτες είναι Ένα Προς Πολλά (One to many) ΑΝ ΘΕΣ ένας πωλητής να έχει πολλούς πελάτες. Μόνο μέσω μιας τέτοιας σχέσης μπορείς να το αναπαραστήσεις αυτό στο βάση.

Πρακτικά, αυτό γίνεται βάζοντας το ID του πωλητή ως πεδίο στον πίνακα των πελατών (και ενεργοποιώντας το referential integrity λειτουργεί ως foreign key).

Αν έχεις κάνει το παραπάνω, ουσιαστικά, σε επίπεδο δεδομένων, δεν έχεις πρόβλημα καθώς η τιμή του ID πωλητή στον πίνακα πελατών "δείχνει" πάντα σε ποιόν πωλητή ανοίκει ο εκάστοτε πελάτης. Φυσικά και δεν χρειάζεται καμία αλλαγή στα ID πελατών και ούτε θές να γίνεται κάτι τέτοιο (ειδικότερα, αν το master ID είναι π.χ. Auto icrement, ούτε λόγος να γίνεται). Ακόμα όμως και αν το αλλάζεις τότε το referential integrity θα φροντίσει να κάνει cascade στο πίνακα πελατών. Αν κάτι τέτοιο δεν συμβαίνει τότε απλά δεν έχεις data integrity.

Δεδομένου οτι ξεμπερδέψαμε με τη βάση, πάμε στην εφαρμογή. Εκεί απλά θες να εμφανίζεται το αντίστοιχο όνομα πωλητή κάθε φορά που αλλάζει ο κωδικός. Και θες αυτό να γίνεται κατά τη διαχείριση των πελατών, αν κατάλαβα καλά. Τα περισσότερα frameworks προσφέρουν components τα οποία μπορούν να δείχνουν άλλη τιμη (π.χ το όνομα του πωλητή) απ' αυτή που πραγματικά χειρίζονται στη βάση (δηλ., το ID του πωλητή στο πίνακα πελατών). Για το σκοπό αυτό μάλιστα, έχουν 2 ζεύγη ιδιοτήτων, ένα για τον κάθε πίνακα. Αν κάτι τέτοιο δεν παρέχεται, τότε μπορείς να το κάνεις απλά χειρονακτικά (εκτελόντας το sql query στο event αλλαγής, υποθέτω). Θέλω, δηλαδή, να πω οτι είναι απλώς θέμα εμφάνισης του ονόματος αντί του ID, δεν τίθεται θέμα αλλαγής της σχεδίασης της βάσης. Επαναλαμβάνω, αν όπως το έχεις τώρα, προκαλείς αλλαγή του master ID του πωλητή τότε είναι λάθος.

Ελπίζω να βοήθησα.

[anon]

Πιστεψέ ξέρω πολύ καλά τις σχέσεις OneToMany και όλες τις υπόλοιπες. Εχω γράψει εκατοντάδες χιλιάδες γραμμές κώδικα, σε Cobol & C & SQL.

Η διαφορά δεν είναι πως το λές, αλλά πως το αντιτωπίζει. Η σχέση πωλητή πελάτη είναι OneToMany στην Java EE? Εαν ναι, μπορώ να αλλάξω τον πωλητή, στον πελάτη; Γιατί αυτό ειναι ένα use case συχνό. Ενω αντιθέτως, το κλασσικό παράδειγμα χρήσης OneToMany, Παραγγελία και γραμμές παραγγελίας, δεν έχει το ανάλογο να αλλάξω μια γραμμή παραγγελίας και να την βάλω να κρέμετε απο άλλη παραγγελία. Στον Πελάτη είναι πάρα πολύ συχνό να του αλλάζω τον πωλητη. Μπορείς να μου πείς, με βάση αυτό το κριτήριο, τι ισχύει;